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PREFACE 


This  guide  provides  an  introduction  to  scheduling.  It  is  the  second  version  of  a  1986 
publication  prepared  by  Mr.  David  D.  Acker,  Mr.  J.  Stanley  Baumgartner  and  Mr.  Michael 
B.  Patterson.  The  1994  revision  was  developed  by  Mr.  William  W.  Bahnmaier  and  Mr.  Paul 
T.  McMahon.  Ms.  Christine  Royer  ret3rped  the  manuscript,  and  Mr.  Gregory  Caruth  and 
Ms.  Deborah  Gonzalez  provided  the  charts  and  graphs.  Editing  was  performed  by  Mrs. 
Esther  M.  Farria  and  Ms.  Alberta  Ladymon  and  printing  by  Mr.  Robert  W.  Ball  of  the 
Defense  Systems  Management  College  (DSMC)  Press. 
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INTRODUCTION 


In  its  simplest  form,  a  schedule  is  nothing 
more  than  a  listing  of  activities  and  events, 
orgaiuzed  by  time.  In  its  more  complex 
form,  it  is  a  process  that  examines  all  pro¬ 
gram  activities  in  terms  of  realistic  con¬ 
straints  of  time,  funds  and  people;  i.e., 
resources.  In  program  management  prac¬ 
tice,  the  schedule  is  one  of  the  most  power¬ 
ful  planning,  control  and  communications 
tools.  Properly  executed,  scheduling  sup¬ 
ports  time  and  cost  estimates,  opens  com¬ 
munications  between  personnel  involved 
in  program  activities,  and  establishes  a 
commitment  to  program  activities. 

Scheduling  is  one  of  the  most  important 
aspects  of  the  program  management  func¬ 
tion  —  planning.  This  is  readily  appar¬ 
ent  when  the  program  structure  or  sched¬ 
ule  is  prepared  as  part  of  a  program's  ac¬ 
quisition  strategy  and  in  the  development 
of  risk,  financial  and  technical  manage¬ 
ment  plans. 

In  addition,  scheduling  is  a  key  element  in 
accomplishing  the  other  management  func¬ 
tions  —  controlling,  organizing,  staffing 
and  leading.  For  example,  controlling  is 
what  is  done  to  keep  abreast  of  program 
execution.  To  achieve  the  goals,  it  is  neces¬ 
sary  to  know  whether  the  program  is  be¬ 
hind,  on  or  ahead  of  schedule,  and  what 


adjustments  are  necessary  to  keep  the  pro¬ 
gram  on  schedule  once  it's  back  on  track. 

Why  does  a  program  manager  (PM) 
sch^ule?  The  simple  answer  is  that  he/ 
she  needs  a  road  map  for  all  program  play¬ 
ers.  In  reality,  scheduling  accomplishes  far 
more  than  the  production  of  "wall  paper" 
network  charts.  Scheduling  supports  key 
program  management  objectives  such  as 
developing  and  fielding  cost-effective 
systems.  As  the  scheduling  process  is  ex¬ 
plored,  the  objectives  and  ^e  means  by 
which  they  can  be  achieved  will  be  ad¬ 
dressed. 

This  guide  is  an  introduction  to  schedul¬ 
ing.  It  is  meant  for  people  who  already 
have  some  experience  in  program  man¬ 
agement  and  for  those  enrolled  in  courses 
at  the  Defense  Systems  Management  Col¬ 
lege  (DSMC). 

The  following  chapters  will  explain  and 
illustrate  scheduling  concepts  and  tech¬ 
niques.  Specifically,  they  will  show  how 
to  plan  schedules,  use  Gantt  and  milestone 
charts,  develop  and  interpret  network  and 
line-of-balance  charts,  manage  time  as  a 
resource,  and  use  commercial  and  govern¬ 
ment  software  scheduling  packages. 
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SCHEDULE  PLANNING 


2.1  SCHEDULING  PROCESS 

One  of  the  first  steps  in  defining  a  project  or 
program  is  to  create  a  Work  Breakdown 
Structure  (WBS).  Guidance  on  creating  a 
WBS  is  provided  in  MILSTD-881B  of  25 
March  1^3.  The  contract  WBS  goes  to  lev¬ 
els  below  the  third  level  and  includes  pro¬ 
cess/work  activities  at  the  lowest  levels. 
These  activities  are  the  basis  for  the  work 
packages  for  cost  accounting  and  the  Cost 
Schedule  Control  System  Criteria.  The 
work  packages  show  the  clear  link  be¬ 
tween  the  organizational  structure  and  the 
WBS.  They  also  contain  the  tasks  or  activi¬ 
ties  which  are  depicted  on  the  schedule 
charts  described  in  this  guidebook. 

Using  a  WBS  as  the  starting  point  for  iden- 
tif5dng  activities  for  constructing  a  network 
or  Gantt  chart  is  an  efficient  approach; 
however,  a  WBS  is  not  always  available.  In 
these  cases,  more  planning  must  be  done  in 
order  to  identify  project  activities  clearly. 

Resources  to  perform  a  project  are  most 
interchangeable  before  the  project  begins. 
Once  resources  have  been  locked  into  bud¬ 
gets,  with  organization  and  manpower  al¬ 
locations,  trading  them  off  can  be  very 
expensive.  A  schedule  should  not  be  ap¬ 
proved  until  resources  have  been  initially 
allocated  to  the  tasks  at  hand,  analyzed  and 
leveled  to  their  most  efficient  use.  Com¬ 
puter  software  tools,  which  will  be  dis¬ 
cussed  later  in  Chapter  8,  help  to  level 
resources. 


2.2  SCHEDULE  STEPS 

•  Create  a  rough  master  schedule  based 
on  cost,  schedule  and  performance  risk; 

•  Create  rough  detailed  implementing 
schedules;  again,  based  on  program  risk; 
and 

•  Iterate  master  and  detailed  sched¬ 
ules  until  proper  balance  is  achieved. 

2.3  NEAR-TERM  AND  FAR-TERM 
(ROLLING  WAVE)  SCHEDULING 

Near-term  scheduling  can  and  should  be 
accomplished  in  sufficient  detail  to  sup¬ 
port  management  at  each  level.  Far-term, 
or  rolling-wave,  scheduling  will  be  less 
precise,  accounting  for  the  alternative  paths 
which  the  program  may  take. 

As  the  program  approaches  each  phase, 
the  schedule  for  that  phase  will  be  fleshed 
out  with  more  detailed  schedule  informa¬ 
tion.  The  schedule  for  the  out-year  phases 
will  be  adjusted  based  on  the  most  current 
information.  However,  this  should  not  be 
taken  as  a  license  to  make  easy  changes  in 
the  schedule.  Every  effort  should  be  made 
to  maintain  the  original  schedule. 

2.4  TRADE-OFFS 

There  is  always  a  trade-off  between  cost, 
schedule  and  performance,  and  within 
each  of  these,  there  is  also  the  risk  factor. 
Cost  includes  all  resources:  people,  money. 
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equipment  and  facilities.  Performance 
includes  quality  and  the  supportabiUty 
parameters. 

The  best  schedule  is  the  one  that  supports 
the  best  trade-off  between  these  competing 
demands. 

2.5  DURATION  ESTIMATION 
METHODS 

•  Analogy  -  Based  on  experience  of 
similar  programs. 

•  Parametric  Estimating  -  Based  on 
development  of  an  estimating  relationship, 
i.e.,  formula. 

•  Bottoms-up  Aggregation  -  Zero- 
based  build  of  schedule  requirements. 

2.6  SOURCES  OF  SCHEDULING 
INFORMATION 

•  Previous  Experience  -  Lessons 
learned  from  own  successes  and  failiures. 

•  Functional  and  Technical  Experts  - 
Advice  from  successful  practitioners. 

•  Other  System  Requirements 

—  PPBS  is  Calendar  Year  driven 
events. 

—  Requirements  Generation  Sys¬ 
tem  is  user/ customer  input  on  when  prod¬ 
uct  or  system  required. 

•  Other  Programs  -  Relate  to  analogy 
method  of  estimating  duration. 

•  Regulations,  Directives  and  Guid¬ 
ance  -  Required  reviews  and  milestones. 


2.7  SCHEDULE  ADJUSTMENTS 

•  Crashing  a  Network  -  Reducing  ac¬ 
tivity  times  by  spending  more  money  for 
resources. 

•  Resource  Adjustments  -  Changes  in 
resource  funding  and/ or  personnel  levels; 
Congressional,  Office  of  the  Secretary  of 
Defense,  component  generated. 

•  New  Information  -  Technology, 
threat  changes,  test  failures  and  successes. 

2.8  SUMMARY 

The  roots  of  successful  scheduling  lie  in  the 
WBS.  The  WBS  represents  the  project  and 
its  parts.  It  is  divided  into  a  sufficient  num¬ 
ber  or  levels  to  allow  each  task  to  be  speci¬ 
fied  in  terms  of  resources  —  such  as  per¬ 
sonnel,  equipment,  facilities  —  and  time. 
In  addition,  the  precedence  relationships 
between  the  taste  are  specified,  as  mile¬ 
stones,  or  deliverables  such  as  tests,  reports 
and  receipt  of  equipment  needed  for  the 
project  to  proceed. 

The  network  can  be  created  on  a  computer 
or  by  the  use  of  labels  or  batches  of  paper 
posted  on  a  whiteboard.  Although  the  lat¬ 
ter  method  may  appear  overly  simple,  the 
payoff  is  that  all  team  members  who  are 
contributing  to  the  project  plan  can  easily 
see  the  growth  of  the  plan  and  the  task 
interrelationships. 

With  this  information  in  place,  one  can 
schedule  the  project.  Schedules  with  ap¬ 
propriate  detail  are  then  developed  for  the 
different  levels  of  management. 
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GANTT  CHARTS 


3.1  SCHEDUUNG  WITH  GANTT 
CHARTS 

Henry  L.  Gantt  contributed  to  the  technol¬ 
ogy  of  scheduling  in  the  early  years  of  the 
20th  Centiuy  with  an  easy-to-use  bar  chart 
method  that  communicated  visually,  with- 
outconfusion.  Gantt's  "daily  balance  chart" 
was  a  significant  breakthrough.  Suddenly, 
the  overall  program  schedule  could  be  seen 
at  a  glance,  and  the  start/ stop  times  of  the 
program's  individual  components.  A  Gantt 
chart  can  be  superimpos^  with  ease  on  a 
calendar.  Then,  by  shading  in  each  bar  as 
progress  is  made,  the  manager  can  easily 
measure  actual  progress  against  the  sched¬ 
ule.  An  example  of  a  simple  bar  chart  is 
shown  in  Figure  3-1. 


Now 

Tinw(ll0filht) 


Actual  I  I  SdwduM  TMtoatonaa 
Progreta  Activity 

Figura  3-1.  Gantt  (Bar)  Chart 

For  the  past  70  years,  Gantt  charting  has 
been  one  of  the  best  ways  to  schedule  ac¬ 
tivities,  for  the  following  reasons: 


•  Effective  communication; 

•  Easy  to  prepare  and  use; 

•  Show  key  activities  with  specific  start 
and  completion  time  (schedule  and  actual); 
and 

•  Relate  schedules  to  calendar  dates 
and  to  days  or  weeks  from  program  start  to 
completion. 

Figure  3-1  shows  that  milestones  may  be 
added  to  Gantt  charts  to  display  significant 
events.  In  fact,  it  may  be  appropriate  to 
show  a  number  of  milestones  associated 
with  a  single  bar. 

A  shortcoming  of  Gantt  charts  is  the  lim¬ 
ited  information  they  portray.  Dependency 
and  other  interrelationships  among  activi¬ 
ties  are  difficult  to  display  because  Gantt 
charts  handle  a  limited  degree  of  complex¬ 
ity.  Figure  3-2  shows  how  a  Gantt  chart  can 
provide  a  clear,  but  limited,  picture  of  de¬ 
pendencies  and  progress.  The  Gantt  chart 
can  present  a  history  of  changes  and  re¬ 
scheduling  occurring  on  a  program;  how¬ 
ever,  this  is  done  more  frequently  on  mile¬ 
stone  charts,  which  will  be  discussed  in  the 
next  chapter. 

Modem  computer  scheduling  programs 
which  show  dependencies  of  activities  in 
Gantt  chart  format  are  being  developed. 
These  programs  will  be  discussed  in 
Chapter  8. 


Activity 

Dependency 

Relationship 

Time 

req'd 

Production 

None 

4mos 

Assembly 

75%  of  production 

1  mo 

Testing 

100%  of  assembly 

IV,  mos 

0 

12  3  4 

5 

6 

Time  (Months) 

Figure  3*2.  Gantt  Chart  Showing  Dependency 


3.2  SUMMARY 


As  a  scheduling  tool,  the  Gantt  chart  is 
simple,  communicates  well,  and  displays 
calendar  an*.,  significant  program  dates. 
Because  of  its  simplicity  and  ease  of  inter¬ 


pretation,  it  is  a  particularly  good  tool  for 
communicating  to  higher  management 
when  information  must  be  presented 
quickly  and  efficiently.  However,  the  chart 
is  limited  in  the  degree  of  detail  and  inter¬ 
relationships  it  can  portray. 


PROS: 


CONS: 


Table  3-1 .  Pros  and  Cons  of  Gantt  Charts 


•  Easy  to  understand,  update  and  prepare 

•  Inexpensive  preparation 

•  Reliable  estimates  can  be  developed  when  the  work  Is  repetitive  and  when  the  product  is  easy  to 
measure  quantitatively 


•  Only  as  reliable  as  the  estimates  on  which  they  are  based:  looking  at  the  chart  doesn't  indicate 
which  estimates  are  the  most  reliable 

•  Hard  to  visualize  activity  dependencies  in  complex  projects.  (This  is  changing  with  the  advent  of 
modem  computer  scheduling  programs.) 

•  Doesn't  allow  quick  or  easy  exploration  of  the  consequences  of  alternative  actions 
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MILESTONE  CHARTS 


4.1  MILESTONE  SCHEDULING 

Milestone  charts  are  event-oriented, 
whereas  Gantt  charts  are  activity-oriented. 
For  a  partiailar  program,  a  setof  key  events, 
or  milestones,  are  selected.  A  nulestoneis 
a  scheduled  event  that  will  occur  when  a 
particular  activity  is  started  or  completed. 
Milestones  are  selected  from  a  program's 
Acquisition  Strategy  Report  (ASR)  and  vi¬ 
sually  depicted  on  the  Program  Structure 
or  Schedule;  see  DoD  5000.2M  for  details. 
By  reviewing  the  status  of  key  milestones, 
one  can  assess  quickly  the  overall  program 
status. 

Although  milestone  charts  can  present  more 
information  than  bar  charts,  they  share  one 
important  drawback:  they  invite  surprises. 
A  surprise  can  occur  when  the  number  of 
displayed  milestones  is  too  limited  or  when 
interdependencies  are  not  portrayed.  The 
result  may  be  that  the  PM  does  not  know 
the  status  of  a  key  event  until  it  occurs,  or 
vmtil  it  fails  to  occur  when  scheduled.  A 
well-conceived  milestone  status  report  can 
provide  early  warning  of  a  potential  prob¬ 
lem.  Early  problem  recognition  is  a  key  to 
successful  program  management. 

The  milestone  scheduling  technique  uses  a 
symbology  consisting  of  arrows  and  dia¬ 
monds,  or  similar  designators,  to  show 
originally  planned  event  dates  and  the 
changed  dates.  Figure  4-1  shows  symbols 
used  by  the  Air  Force  Material  Command’s 
Electronic  Systems  Center  (ESC)  and  the 


meaning  of  combinations  of  the  symbols. 
Program  management's  scheduling  soft¬ 
ware  often  has  unique  symbology  to  desig¬ 
nate  activities  and  milestones  which  dif¬ 
fers  somewhat  from  the  Air  Force  s)anbol- 
ogy.  Any  symbol  can  be  used;  mechanics 
are  not  as  important  as  principles. 


standard  symbols  havo  basn  adsplsd  tor  Air  FOrcs 
mllsstons  schsdulss.  Ths  most  oommon  symbols  ussd 
and  thsir  maanbigs  ars  shown  bslow. 
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4 
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Uass 
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0 

Ct 

Anticteatsd  slip  —  rsschsdulsd 
compMon 

♦ 

0 

Actual  slip—  rsschsdulsd 
complotlon 

♦ 

t 

Actual  slip  —  actual  complotlon 

t 

0 

Actual  complotlon  ahead  of 
schsdu^v 

L 

_ D 

Time  span  action 

t- 

_ D 

Progress  along  timo  span 

Q_ 

Continuous  action 

FIgura  4-1.  MilMlom  Symbols 


Figure  4-2  is  an  example  of  a  milestone 
chart.  Arrows  are  used  to  show  resched¬ 
uled  events,  while  diamonds  indicate  the 
originally  planned  schedule.  As  a  result, 
the  milestone  schedule  improves  on  the 
Gantt  chart  by  retaining  the  baseline  dates, 
while  incorporating  changes  in  planned 
future  events. 
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Figure  4*2.  Milestone  Chart 


The  milestone  chart  records  the  manager's 
assessment.  For  example,  a  manager  might 
reasonably  predict  that  a  one-month  slip  in 
the  start  of  software  development  will  prob¬ 
ably  result  in  a  several-month  slip  in  com¬ 
pleting  the  engineering  and  manufactur¬ 
ing  development  phase.  The  milestone 
chart  does  not  provide  the  assessment;  the 
manager’s  experience  does.  This  is  the  key 
to  understanding  the  use  of  milestone 
charts.  Unless  the  activity  and  interrela¬ 
tionships  of  milestones  are  understood,  the 
chart  tells  only  what  has  happened  and 
what  is  yet  to  happen.  However,  by  cou¬ 
pling  the  information  on  what  has  hap¬ 
pened  with  the  manager's  experience  and 
knowledge,  the  PM  can  predict  more  accu¬ 
rately  what  will  occur  in  the  future. 

The  milestone  scheduling  technique  shows 
what  is  scheduled,  what  has  happened 
and  changes  in  plans.  The  technique  is  not 
as  useful  for  forecasting  schedule  changes 
as  are  the  network  and  line-of-balance  tech¬ 
niques  discussed  in  later  chapters. 

4.2  STRENGTHS 

Like  the  Gantt  chart,  the  milestone  chart  is 
an  effective  method  of  communication. 
The  symbology  is  relatively  standard  and 
simple  to  use.  The  chart  presents  actual 
progress  against  a  baseline  plan  and  dis¬ 
plays  changes  in  plans.  The  mechanics  of 
constructing  a  milestone  chart  are  relatively 
easy.  Many  defense  contractors  use  mile¬ 
stone  charts  extensively,  and  the  charts 
have  become  a  mainstay  of  program  man¬ 
agement. 


43  LIMITATIONS 

As  with  bar  charting,  a  major  weakness  of 
milestone  charting  is  the  inability  of  the 
chart  to  clearly  show  interdependencies 
and  the  interaction  among  activities.  This 
may  be  especially  true  if  the  chart  is  pre¬ 
pared  manually.  If  a  PM  focuses  on  a  rela¬ 
tively  simple  milestone  format,  he/she  may 
lose  sight  of  the  complexity  of  the  relation¬ 
ships  among  various  program  tasks. 

When  milestone  charts  are  used  on  com¬ 
plex  programs,  they  are  usually  the  prod¬ 
uct  of  network  analysis.  If  the  milestone 
chart  is  provided  by  a  computer  software 
application  and  the  use  of  network  analy¬ 
sis,  it  may  also  show  activity  dependency. 
Milestone  chart  preparation  is  relatively 
simple,  but  developing  and  analyzing  the 
information  going  into  the  charts  can  be 
time-consuming.  A  controlled  flow  of  ac¬ 
curate,  timely  and  appropriate  informa¬ 
tion  to  assist  in  constructing  milestone 
charts  is  important. 

4.4  SUMMARY 

Milestone  charting  represents  a  simple  and 
effective  means  for  displaying  the  actual 
versus  the  planned  progress  of  a  program, 
and  for  showing  schedule  changes  that 
have  occurred.  These  charts  emphasize 
start  and  completion  dates  rather  than  the 
activities  that  take  place  between  these 
dates. 

Milestone  charts  generated  manually  dis¬ 
play  very  limited  dependency  information 
However,  dependencies  may  be  depicted 
in  some  software  scheduling  applications. 
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5 

NETWORK  SCHEDULING 


"Network  scheduling  is  a  prime  exampleof 
the  value  of  graphic  art  to  management 
The  visual  display  has  obvious  worth  in 
direct  communication  between  program 
managers,  supervisors,  and  workers;  all  of 
them  see  the  same  picture  of  anticipated 
action  and  they  can  discuss  it  in  the  well- 
defined  terms  associated  with  networks." 
— James  L.  Riggs  and  A.  James  Kalbaugh' 

The  shortcomings  of  Gantt  and  milestone 
charts  gave  rise  to  network  scheduling  in 
the  1950s.  The  network  techniques  pro¬ 
vide  a  method  of  graphically  displaying 
information  that  caimot  be  presented  with 
bars  or  milestones. 

To  analyze  a  program,  it  is  separated  into 
activities.  Each  activity  is  based  on  a  par¬ 
ticular  undertaking  and  is  defined  by  a 
distinct  start  and  completion  point.  Net¬ 
work  scheduling  provides  a  method  of  find¬ 
ing  the  longest,  most  time-consuming  path. 
This  gives  the  PM  two  important  tools. 
First,  he/she  is  able  to  estimate  more  accu¬ 
rately  the  total  time  from  program  start  to 
completion.  Second,  by  being  able  to  iden¬ 
tify  items  on  the  critical  (or  longest)  path,  as 
opposed  to  less  critical  tasks,  the  PM  is  able 
to  analyze  and  prioritize  problems  as  they 
arise. 

5.1  PROGRAM  EVALUATION  AND 
REVIEW  TECHNIQUE 

The  Program  Evaluation  and  Review  Tech¬ 
nique  (PERT)  was  developed  in  1957 under 
the  sponsorship  of  the  U.S.  Navy  Special 


Project  Office.  The  Navy  wanted  PERT  as 
a  management  tool  for  scheduling  and  con¬ 
trolling  the  Polaris  missile  program,  which 
involved  250  prime  contractors  and  more 
than  9,0(X)  subcontractors.  The  PM  had  to 
keep  track  of  hundreds  of  thousands  of 
tasl^. 

PERT  helps  the  PM  answer  the  following 
questions: 

•  When  is  each  segment  of  the  pro¬ 
gram  scheduled  to  begin  and  end? 

•  Considering  all  of  the  program  seg¬ 
ments,  which  segments  must  be  finished 
on  time  to  avoid  missing  the  scheduled 
program  completion  date? 

•  Can  resources  be  shifted  to  critical 
parts  of  the  program  (those  that  must  be 
completed  on  time)  from  noncritical  parts 
(those  that  can  be  delayed)  without  affect¬ 
ing  the  overall  scheduled  completion  date 
for  the  program? 

•  Among  the  myriad  of  program  tasks, 
where  should  management  efforts  be  con¬ 
centrated  at  any  particular  time? 

Most  activities  in  a  PERT  network  take  a 
long  time  to  accomplish;  therefore,  time  is 
usually  expressed  in  days  or  weeks. 

Because  PERT  was  intended  to  increase  a 
PM’s  control  in  situations  where  time  esti¬ 
mates  were  difficult  to  make  with  confi¬ 
dence,  time  estimates  were  calculated  from 
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a  probability  distribution  (see  Figure  5-1). 
The  developers  of  PERT  chose  the  beta 
probability  distribution  because  it  could 
accommodate  non-symmetrical  situations. 
They  assumed  that  the  probability  of  an 
estimate  being  too  optimistic  would  not  be 
equal  to  the  probability  that  the  same  esti¬ 
mate  would  be  too  pessimistic.  That  is,  if 
estimated  times  could  be  compared  against 
actual  completion  times  in  a  number  of 
cases,  the  variation  would  look  like  the 
curve  in  Figure  5-1. 


To  calculate  the  estimated  time  for  any 
activity,  compute  the  mode  of  the  beta 
distribution  using  the  mode(m),  the  most 
optimistic  (a),  and  most  pessimistic  (b)  times 
as  the  basic  data  points  for  constructing  the 
distribution.  The  equation  for  this  calcula¬ 
tion  is: 

t  _  a+4m+b 
^  6 

This  is  an  estimate  of  the  weighted  average, 
or  mean  time,  for  an  activity. 

According  to  Hugh  McCullough,  former 
Polaris  project  business  manager,  PERT 
had  a  disciplinary  effect  on  the  project, 
which  had  a  20,000  event  network.  The 
successful  application  of  PERT  is  credited 
with  saving  two  years  in  bringing  the  Po¬ 
laris  missile  submarine  to  combat  readi¬ 
ness. 


During  the  next  few  years,  PERT  became 
widely  used  throughout  systems  acquisi¬ 
tion  programs.  However,  a  few  years  later, 
the  use  of  PERT  declined  and,  by  the  1 970s, 
it  was  only  occasionally  employed  in  de¬ 
fense  systems  programs.  Recently,  in  the 
late  1980s  and  early  1990s,  it  has  again 
become  relatively  popular,  particularly  in 
the  private  sector.  This  resurgence  is  due 
in  part  to  the  development  of  PERT  soft¬ 
ware  or  other  networking  software  pro¬ 
grams  that  can  be  run  on  microcomputers. 

Why  did  PERT  go  through  such  a  rapid  rise 
and  then  decline?  Frequently,  it  was  over¬ 
applied.  When  PERT  was  combined  "  ith 
cost  data  or  other  nonscheduling  asp  f 

program  management,  it  became  cu  r ; 
some.  Department  of  Defense  (DoD)  PMs 
and  defense  contractors  spent  immense 
amounts  of  time  collecting  and  entering 
detailed  data.  As  a  result,  the  cost  of  main¬ 
taining  PERT  systems  far  outweighed  the 
benefits. 

Eventually,  DoD  and  the  defense  industry 
returned  to  simpler  techniques  like  mile¬ 
stone  charts  and  bar  charts.  However,  the 
private  sector  continues  to  make  good  use 
of  network  scheduling  in  areas  such  as  new 
product  development,  construction  and 
major  maintenance  activities.  Defense  PMs 
have  also  begun  to  use  PERT  to  get  a  firmer 
grip  on  critical  path  activities  and  because 
software  packages  make  PERT  easier  to 
use. 

In  spite  of  misuses  that  have  occurred  in 
PERT  appliations,  the  technique  can  be  a 
very  useful  tool  because  it  enables  the  man¬ 
ager  to  visualize  the  entire  program,  see 
interrelationships  and  dependencies,  and 
recognize  when  delays  are  acceptable. 
Thus,  the  manager  is  better  able  to  assess 
problems  as  the  program  evolves. 
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In  order  to  apply  PERT  and  similar  net¬ 
working  techniques,  it  is  important  that 
following  conditions  exist: 

1.  The  program  must  consist  of  clearly 
defined  activities,  each  with  identifiable 
start  and  completion  points. 

2.  The  sequence  and  interrelationships 
of  activities  must  be  determined. 

3.  When  all  individual  activities  are 
completed,  the  program  is  completed. 

Many  program-oriented  industries,  such 
as  aerospace,  construction  and  shipbuild¬ 
ing,  meet  these  criteria  and  use  a  network 
scheduling  technique.  Many  defense  sys¬ 
tem  programs  also  meet  these  criteria,  and 
the  judicious  use  of  network  scheduling 
techniques  may  provide  the  PM  with  a 
useful  tool. 

5.2  CRITICAL  PATH  METHOD 

The  Critical  Path  Method  (CPM)  is  activity- 
oriented,  concentrating  on  activity  start 
(Early  Start/ES;  Late  Start/LS)  and  finish 
times  (Early  Finish/EF;  Late  Finish/LF); 
whereas  PERT  is  event-oriented,  concen¬ 
trating  on  early  event  time  (TE)  and  late 
event  time  (TL). 

Like  PERT,  CPM  is  composed  of  three 
phases:  planning,  scheduling  and  control¬ 
ling.  Developed  in  1957  by  J.  E.  Kelly  of 
Remington-Rand  and  M.  R.  Walker  of 
DuPont  to  aid  in  scheduling  maintenance 
shutdowns  in  chemical  processing  plants, 
CPM  has  enjoyed  more  use  than  any  other 
network  technique. 

The  CPM  technique  brings  the  cost  factor 
more  prominently  into  the  scheduling  and 
controlling  process  than  PERT  does.  When 
time  can  be  estimated  closely  and  when 
labor  and  material  costs  can  be  calculated 


quite  accurately  early  in  a  program,  the 
CPM  technique  is  superior  to  PERT.  When 
there  is  much  uncertainty  and  when  con¬ 
trol  over  time  outweighs  control  over 
costs,  PERT  is  a  better  technique  to  use. 
However,  the  basic  networking  principles 
in  PERT  and  CPM  are  similar. 

In  a  common  version  of  CPM,  two  time 
and  cost  estimates  are  given  for  each  activ¬ 
ity  in  the  network:  the  normal  estimate  and 
the  crash  estimate  (see  Figure  5-2).  The 
normal  time  estimate  approximates  the 
most  likely  time  estimate  in  PERT;  the  nor¬ 
mal  cost  is  the  cost  associated  with  finish¬ 
ing  the  program  in  the  normal  time.  The 
crash  time  estimate  is  the  time  that  will  be 
required  to  finish  an  activity  if  a  special 
effort  is  made  to  reduce  program  time  to 
minimum;  the  crash  cost  is  the  cost  associ¬ 
ated  with  performing  the  effort  on  a  crash 
basis  so  as  to  minimize  the  time  to  comple¬ 
tion. 


FIgura  5^  CPM  TliiM-Co«t  Curv* 

5.3  DEVELOPING  A  NETWORK 

Although  CPM  and  PERT  are  conceptually 
similar,  symbols  and  charting  techniques 
vary.  Historically,  PERT  has  utilized  prob¬ 
ability  techniques  to  calculate  activity  time 
while  CPM  generally  has  not.  The  follow¬ 
ing  procedures  apply  to  both  CPM  and 
PERT. 


1.  Identify  all  individual  tasks  compris¬ 
ing  the  program. 

2.  Determine  the  expected  time  to  com¬ 
plete  each  activity.^ 

3.  Determine  precedence  and  interre¬ 
lationships  existing  among  the  activities. 

4.  Develop  a  network  diagram  present¬ 
ing  these  activities  in  proper  sequence  and 
reflecting  any  dependency  relationships. 
Activities  are  indicated  by  lines;  events  or 
milestones  are  indicated  by  circles.  Depen¬ 
dency  or  sequencing  relationships  among 
activities  on  separate  paths  can  be  shown 
by  dotted  lines. 

5.  Complete  and  annotate  the  cumula¬ 
tive  time  required  to  reach  each  milestone 
along  the  paths,  which  will  indicate  the 
earliest  time  work  can  start  on  the  next 
activity.  The  final  number  will  indicate  to¬ 
tal  time  required  to  complete  a  particular 
path. 

6.  Identify  the  critical  path.  This  is  the 
sequence  of  events,  or  route,  taking  the 
longest  time  to  complete. 

7.  Starting  at  the  program  completion 
milestone  on  the  right  side  of  the  diagram, 
begin  working  backward  and  compute  the 
latest  time  an  activity  can  start  without 
delaying  theoverall  program.  For  example, 
if  the  total  program  takes  40  weeks  and  the 
final  activity  requires  five  weeks,  this  activ¬ 
ity  cannot  begin  later  than  week  35.  For 
PERT,  the  difference  between  the  earliest 
event  time  and  the  latest  event  at  each 
event  is  the  slack  time  or  float.  The  critical 
path  contains  no  slack  time;  i.e.,  free  time. 
For  CPM,  the  difference  between  the  latest 
start  and  earliest  start  of  an  activity  is  also 
the  slack  or  float. 


Bgure  5-3  shows  a  simple  network  dia¬ 
gram  for  a  computer  installation  program 
which  will  require  20  days  to  complete. 
The  critical  path  is  F-G;  any  delay  on  this 
path  will  delay  final  completion  of  the  pro¬ 
gram  by  a  corresponding  amount.  How¬ 
ever,  a  delay  of  one  day  can  occur  along 
path  C-D-E  or  five  days  along  path  A-B-E, 
and  the  final  program  completion  date 
would  not  be  extended. 

Critical  path  programs  may  be  either  activ¬ 
ity-oriented  or  event-oriented.  This  means 
that  the  input  and  output  data  are  associ¬ 
ated  with  either  activities  or  events. 

Many  CPM  programs  and  a  few  PERT 
programs  require  that  events  (circles  on 
the  diagram)  be  described  in  ascending 
order,  as  has  been  done  in  the  following 
example  involving  the  installation  of  a  com¬ 
puter.  However,  this  is  not  always  done 
because  it  inhibits  the  flexibility  of  the  net¬ 
work. 

Another  recent  improvement  in  the  deter¬ 
mination  of  activity  time  is  the  use  of  learn¬ 
ing-curve  theory.  Inl993,C.TeplitzandJ. 
Amor®  develop^  a  technique  for  applying 
learning  curves  to  predict  estimated 
completion  times  for  a  project  more  accu¬ 
rately.  As  an  example  of  their  technique,  a 
project  of  building20  houses  was  predicted 
to  take  288  days  when  using  experienced 
workers.  The  project  time  was  then  revised 
to  384  days  by  using  learning-curve  esti¬ 
mates  for  less-experienced  workers.  This 
revised  time  headed  off  many  of  the  delays 
and  headaches  that  would  have  resulted 
from  a  promised  288-day  completion  date. 

5.4  CONVERTING  AN  UGLY 
DUCKLING  TO  A  SWAN 

Although  the  traditional  CPM  technique 
provides  useful  scheduling  data  about  a 
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program,  it  is  difficult  to  draw  the  chart  to 
match  a  time  or  calendar  scale.  The  critical 
path  and  slack  times  can  be  computed  eas- 
ily,buttheyarenotFeadilyapparent.  Also, 
tMs  technique  does  not  display  progress  to 
date.  Consequently,  a  simpler  charting 
technique,  sometimes  called  the  Swan 
network  (as  opposed  to  the  Ugly  Duck¬ 
ling)  is  useful. 

Let's  take  an  Ugly  Duckling  network  (Fig¬ 
ure  5-4a)  and  turn  it  into  a  Swan  network 
(Figure  5-4b). 

In  Figure  5-4a  the  letters  in  parenthesis 
represent  activities  between  the  start  (S) 
and  completion  (C)  points.  Numbers  indi¬ 
cate  weeks  required  for  each  activity. 

In  Figure  5-4b,  activity  A  is  represented  by 
a  horizontal  bar  four  weeks  long.  Events 
are  represented  by  vertical  lines  or  "fences"; 
for  example,  the  fence  after  B  means  B  must 


be  completed  before  E  and  F  can  begin  (the 
sameasinFig:ure5-4a).  The  result  is  shown 
in  Figure  5-4b. 

What  does  the  Swan  network  show? 

•  Critical  path.  Time  constraints  need 
not  be  calculated.  There  are,  in  fact,  two 
critical  paths,  B-F-I  and  C-J-K,  whidi  are 
critical  because  each  has  a  continuous  se¬ 
ries  of  activities  and  take  the  same  amotmt 
of  time.  There  is  no  slack  in  either  path. 
Also,  the  figure  has  a  time  scale,  which 
adds  greatly  to  the  meaning  of  the  chart. 

•  Weeks  from  start.  Scales  for  "calen¬ 
dar  weeks"  and  "weeks  to  completion"  can 
be  added.  In  Figure  5-4b,  the  program  is 
scheduled  for  completion  after  14  weeks. 

•  Slacktime.  Thenetworkshowswhere 
there  is  slack  in  the  schedule  and  the  extent 
of  that  slack.  For  example,  there  are  only 
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two  weeks  of  slack  in  the  A-D-H  path.  If 
B-F-I  and  C-J-K  were  shortened  by  more 
than  two  weeks,  A-D-H  would  become  a 
critical  path.  This  changing  of  critical  paths 
is  important  when  conducting  "what  if  " 
exercises. 

The  high  visibility  offered  by  the  Swan 
network  does  the  following: 

•  Communicates  easily  and  efficiently; 


•  Motivates,  if  the  level  of  detail  is 
sufficient,  each  person  associated  with  a 
program  activity  can  see  how  he/she  af¬ 
fects  the  schedule,  and  vice  versa; 

•  Gets  top-level  attention,  primarily 
because  it  transmits  information  in  an  un¬ 
derstandable  format; 

•  Makes  omissions  and  errors  easier  to 
detect.  As  an  example,  one  company 


discovered  by  using  the  Swan  network  that 
two  test  activities  on  the  critical  path  had 
been  omitted.  This  was  not  apparent  in  the 
Ugly  Ehickling  network; 

•  Shows  early  start,  early  finish,  late 
start  and  late  finish;  and 

•  Avoids  reams  of  tab  runs  and  print¬ 
outs,  usually  provided  (but  not  used)  for 
the  Ugly  Duckling  technique. 

5.5  DEVELOPING  A  SWAN  NETWORK 

The  Swan  network  can  be  developed  by  the 
following: 

•  Translating  from  another  network,  as 
shown  in  the  preceding  example; 

•  From  a  list  of  the  preceding  and  fol¬ 
lowing  events  or  activities,  as  in  the  net¬ 
working  problem  that  follows; 

•  From  scratch,  with  the  sequencing 
and  time  estimating  required  in  originat¬ 
ing  any  network;  and 

•  From  milestones. 

A  "fence"  in  the  Swan  network  is  usually  a 
milestone,  such  as  a  review  or  a  major 
event,  regardless  of  how  the  network  is 
developed. 

Actual  progress  can  be  shown  in  the  same 
way  as  on  a  Gantt  chart.  Shading  on  each 
bar  indicates  progress  made.  A  vertical 
"now"  line  shows  whether  activities  are  on, 
ahead  of  or  behind  schedule,  and  by  how 
much. 

Now,  let’s  go  through  an  exercise  involv¬ 
ingnetworkscheduling.  Take  time  to  work 
the  problem  shown  in  the  following  para¬ 
graphs. 


5.6  NETWORK  SCHEDULING 
PROBLEM 

Assume  you  are  a  PM.  Your  objective  is  to 
schedule  the  activities  on  your  program  so 
that  one  lot  of  missiles  will  be  assembled 
and  shipped  to  the  test  site  within  56  days 
at  the  least  cost.  Use  any  technique  with 
which  you  feel  comfortable.  If  you're  not 
comfortable  with  some  other  technique, 
use  the  Swan  network. 

Proceed  in  the  following  manner,  using 
Tables  5-1  and  5-2  provided. 

•  Using  lined  tablet  paper,  lay  out  the 
network  schedule.  This  will  show  the  criti¬ 
cal  path  and  total  number  of  days  required. 

•  Identify  the  initial  critical  path  (num¬ 
ber  of  days). 

•  Using  Table  5-2,  crash  the  network 
by  selecting  the  final  critical  path  and  re¬ 
lated  costs  that  will  ensure  completion  of 
the  program  in  56  days  at  the  least  cost. 

Some  key  points: 

•  Crash  only  along  the  critical  path. 

•  When  an  activity  is  shortened,  one  or 
more  new  critical  paths  may  emerge.  Par¬ 
allel  critical  paths  increase  risk  dramati¬ 
cally. 

•  Generally,  least  additional  cost  is  the 
criterion  used  to  select  which  task  to  crash, 
but  other  considerations  (e.g.,  personnel 
hours)  could  be  used. 

It  will  probably  take  about  20  minutes  for 
you  to  deteimine  the  solution.  Two  "school" 
solutions  are  at  the  back  of  this  book  (Ap¬ 
pendix  B). 
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Tabto  9-1.  AotIvMM. 


TlmM  wid  Costs 


ACTIVITY* 

ACnVITY 

DEPENDENCY 

TIME 

(WORK  DAYS) 

NORMAL 

COST 

($000) 

1-2  Fai».  Initial  OuManca 

Aaaambllaa 

Nona 

12 

80 

1-3  Control  Fabrication 

Nofta 

2» 

98 

1-4  Roekat  Motor  Fabrication 

Nona 

25 

106 

1-6  Procaaa  Warbaada  (QFE) 

Nona 

16 

3rs 

2-6  Additional  QuMaitca 

Aaaambllaa 

1-2 

20 

90 

2-3  GuManca  Chackout  and 

Sub- Aaaambllaa 

1-2 

16 

120 

3-6  QAC  Sub-Aaaambllaa 

1-3, 2-3 

8 

70 

4-6  Machine  Roekat  Motora 

1-4 

12 

30 

5-6  Mlaalla  Aaaambly 

3-5, 4-6. 1-5 

6 

376 

6-7Taat 

2-6, 5-6 

10 

826 

7-6ShlptoTa8tSlta 

6-7 

8 

30 

Nots:  s.  TsMs  5-2  contains  "erssh*  dsts. 


Tabis  S-2.  Activity  TlmsK^  Rslatlonships 


ABttvim-g 

AcUvtlylri 

Actlvltvl-5 

ActivtlyZ-a 

Tkna  Coat 

Tima 

Coat 

Ikna 

Coot 

Tkm  Coot 

Tkno 

Coot 

Tbno  Coot 

10  826 

22 

106 

26 

110 

14  80 

18 

976 

14  1326 

30 

117 

at 

115 

12  676 

16 

100 

12  ISO 

18 

127 

20 

142 

AfiMYltyM 

AfitlYltyfr7 

AfiUyttyJtB 

Tkna  Coat 

Tkiw 

Coot 

Tima 

Coot 

Tlmo  Coot 

Tlmo 

Coot 

6  6 

10 

36 

4 

80 

6  6 

6 

80 

8 

« 

Nets:  Crash  tkns  Is  In  work  days  and  cost  Is  In  thousmtfso^dolisrs. 

Crash  costs  ineluds  nomuri  schsduls  costs.  For  sx»id>lo,  ths  Activity  1-2  crash  cost  ($82.SK) 
InchJdss  ths  normal  schsduis  cost  of  $60K. 

Ths  acthdty  marksd  *  cannot  bs  'crashsd.* 


5.7  NETWORK  SCHEDULING  WHEN  resources  to  proceed  are  not  always 
RESOURCES  ARE  LIMITED  available. 


In  the  previous  discussion,  the  assumption 
was  that  a  new  activity  could  start  as  soon 
as  preceding  activities  were  completed, 
because  sufficient  resources  were  available 
to  perform  the  work.  In  practice,  however. 


Let's  look  at  an  example  to  illustrate  how 
this  network  differs  in  format  ftxim  previ¬ 
ous  networks.  First,  it  uses  curved  lines  for 
activities,  eliminating  zero-time  activities. 
Second,  it  identifies  each  activity  in  three 


ways:  (1)  by  a  letter  (A),  (B),  (C),  etc.;  (2)  by 
estimated  duration  of  activity  (in  weeks); 
and  (3)  by  number  of  people  available  to 
work  on  the  activity  bas^  on  the  manager's 
estimate  at  the  time  the  network  is  pre¬ 
pared  (see  Figure  5-5). 

The  network  in  Figure  5-5  can  be  shown  in 
another  manner  (see  Figure  5-6).  In  this 
network,  each  activity  is  plotted  on  a  sched¬ 
ule  graph  with  a  horizontal  time  scale: 
duration  of  each  activity  is  represented  by 
the  length  of  that  activity's  line.  Each  activ¬ 


ity  has  a  letter  designation  and,  in  paren¬ 
theses,  number  of  people  assigned  to  that 
activity  at  the  time  indicated  (size  of  work 
group).  The  row  across  the  bottom  dis¬ 
plays  total  people  scheduled  to  work  each 
week.  Thus,  in  this  example,  5-15  people 
will  be  required,  depending  on  the  week 
being  scheduled. 

Now,  let's  suppose  only  nine  people  are 
available  to  work  during  this  nine-week 
period.  What  are  the  alternatives?  A  per¬ 
sonnel  loading  chart  can  be  produced  by 


Figure  5-6.  Limited  Resource  Network  Plotted  on  Schedule  Graph 


5-9 


plotting  the  number  of  people  scheduled  to 
work  in  any  week  against  time  (see  Figure 
5-7). 


Figun  S-7.  Paraomai  UMdIng  Chart  for  Sciwdult  Graph 

If  only  nine  people  are  available,  the  chart 
shows  there  will  not  be  sufficient  workers 
during  the  first,  fourth  and  fifth  weeks. 
There  will  be  sufficient  workers  to  perform 
the  work  scheduled  during  the  second  and 
sixth  week.  Ehiring  the  third,  seventh, 
eighth  and  ninth  weeks,  there  will  be  a 
surplus  of  workers  for  the  work  scheduled. 
The  task  becomes  one  of  rearranging  the 
schedule  so  that,  insofar  as  possible,  the 
peaks  and  valleys  are  evened  out  without 
scheduling  more  work  than  nine  people 
can  do.  It  may  not  be  possible  to  rearrange 
the  network  and  still  finish  the  program  on 
time.  Under  present  circumstances,  there 
will  not  be  enough  workers  to  complete  the 
first  week's  scheduled  work  on  time. 

The  scheduling  problem  under  consider¬ 
ation  can  be  solv^  quickly  by  hand.  How¬ 
ever,  when  there  are  many  activities,  it 
becomes  very  difficult  to  find  the  optimum 
answer,  even  with  a  computer.  A  heuristic 
program  —  a  collection  of  rules  of  thumb 
that  work  —  should  be  used  to  solve  this 
kind  of  problem. 


In  the  above  example,  the  heuristic  ap¬ 
proach  is  to  find  the  activities  having  the 
most  slack  and  attempt  to  delay  them  as 
long  as  possible  without  delaying  comple¬ 
tion  of  the  entire  program.  Delaying  the 
start  of  activity  (C)  for  two  weeks;  activities 
(A)  and  (B)  can  begin  simultaneously  with¬ 
out  exceeding  the  limit  of  nine  workers. 
Continuing  to  apply  this  approach,  the  re¬ 
vised  schedule  could  look  like  that  shown 
in  Figure  5-8. 


FIgun  RwiMd  Sdwduto  Gnph 

When  an  activity  is  delayed  to  improve  the 
schedule,  the  time  delay  is  usually  shown 
by  a  dotted  line.  At  the  end  of  the  third 
week  ill  the  above  example,  there  was  an 
opportunity  to  delay  activities  (D),  (G)  and 
(I).  Activities  (D)  and  (H)  were  delayed  one 
week  and  (I)  four  weeks.  Although  the 
example  is  simple,  a  perfectly  balanced 
schedule  cannot  be  achieved;  however, 
given  this  problem  most  managers  would 
be  happy  with  the  extent  of  this  success. 

5.8  MULTIPROGRAM 
CONSIDERATIONS 

In  his  dissertation  at  Purdue  University  in 
1965,  J.  H.  Mize^  offered  a  methoa  for 
multiprogram  control.  He  developed  a 
noniterative  heuristic  model  that  sched- 
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uled  activities  for  several  operating  facili¬ 
ties  of  a  multiprogram  organization  when 
the  objective  was  to  minimize  due-date 
slippage.  The  outputs  from  program  criti¬ 
cal-path  analyses  became  the  inputs  to  the 
schedule. 

Mize  took  into  account  the  dynamic  rela¬ 
tionships  of  activities-to-activities  and  pro- 
gram-to-program  when  conflicts  arose.  His 
method  is  generally  applicable  to  any  pro¬ 
gram  involving  multiple  projects  which 
are  competing  for  the  same  limited  re¬ 
sources. 

In  1968,  L.  G.  Fendley®  developed  a  system 
based  on  the  concept  of  assigning  the  due 
dates  to  incoming  programs  and  then  se¬ 
quencing  activities  of  the  programs  toward 
meeting  the  due  date.  Using  the  heuristic 
approach,  Fendley  concluded  that  giving 
priority  to  the  activity  with  minimum  slack- 
from-due  date  (his  MSF  rule)  resulted  in 
the  best  performance.  He  used  the  MSF 
rule  to  set  realistic  due  dates  by  determin¬ 
ing  the  amount  of  slippage  that  must  occur 
to  perform  all  programs  rVith  fixed  re¬ 
sources. 

In  1970,  Mize  and  L.  F.  Jordan  applied  a 
simulation  technique  to  the  scheduling  of 
multiengineering  programs.  They  discov¬ 
ered  that  a  rule  based  upon  a  combination 
of  processing  time  and  due  dates  yielded 
good  results. 

All  networking  concepts  can  be  applied  to 
the  scheduling  of  several  programs  jointly 
administered  by  a  single  organization.  For 
example,  consider  the  three  programs 
shown  in  Figure  5-9. 

In  this  example.  Program  A  must  be  com¬ 
pleted  before  Program  B  can  start.  Pro¬ 
gram  C  and  Program  D  may  begin  and  be 


completed  any  time  between  Week  1  and 
Week  6,  respectively.  Thus,  the  dotted  lines 
in  Figure  5-9  indicate  dummy  dependen¬ 
cies  only  and  serve  to  indicate  the  time 
span  available  for  all  four  programs.  Dura¬ 
tion  times  could  be  placed  on  these  dum¬ 
mies  to  achieve  early-start  and  late-finish 
program  dates,  if  they  exist.  The  program 
floats  implied  by  these  dummy  jobs  can  be 
used  in  the  same  way  that  dummy  jobs  are 
used  in  single-program  networks.  For  ex¬ 
ample,  suppose  the  same  resources  are  used 
on  Programs  B  and  C,  but  that  resource 
rec^uirements  exceed  the  availabilities  be¬ 
cause  of  the  simultaneous  demands.  Fig¬ 
ure  5-9  shows  that  the  start  of  Program  C 
can  be  delayed  until  Week  5,  so  that  the 
resources  can  be  fully  employed  on  Pro¬ 
gram  B.  After  Program  Bis  completed,  the 
resources  can  be  released  for  use  on  Pro¬ 
gram  C.  Alternatively,  both  programs  can 
use  the  resources  at  a  reduced  rate,  and 
both  programs  will  then  float  out  (as  long 
as  they  do  not  float  beyond  Week  6).  Whole 
programs  may  be  cost-expedited.  Thus, 
multiprogram  networking  techniques  are 
completely  analogous  to  single-program 
networking  techniques. 

There  is,  however,  one  new  aspect  in 
multiprogram  scheduling:  program  pri- 
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orities.  Suppose  that  Program  C  (Figure  5- 
9)  is  deemed  to  be  the  most  important 
program  and  management  wishes  to  have 
it  start  before  any  other  program.  In  the 
Resource  Allocation  and  Multi-Project 
Scheduling  (RAMPS)  computer  algorithm 
developed  in  1963  at  C-E-I-R,  Inc.  by 
Moshman,  Johnson  and  Larsen,®  the  pro¬ 
gram  priority  is  used  as  a  weighting  factor 
in  scheduling  and  allocating  resources 
among  competing  alternative  uses  in  the 
multiprogram  network. 

In  general,  the  iterative  use  of 
multiprogram-level  and  program-level 
network  methods  provides  a  medium 
through  which  PMs  and  department-level 
managers  may  devise  integrated  total 
plans.  In  1975,  Woodworth  and  Dane^ 
found  that  multiple  networks,  submitted 
by  individual  PMs,  could  be  merged  into 
a  multiprogram  network.  Several  multi¬ 
program  network  schedules  may  be  de¬ 
veloped,  using  various  assumptions  about 
priorities  and  resources.  These  alternative 
schedules  may  then  be  examined  in  staff 
meetings  attended  by  each  PM  and  the 
multiprogram  manager.  The  best  multi¬ 
program  schedule  may  then  be  selected 
based  on  discussions  and  criticisms  by  ev¬ 
eryone  involved.  Of  course,  several  itera¬ 
tions  of  the  schedule  may  be  required  be¬ 
tween  the  program  and  multiprogram  level 
before  an  acceptable  plan  is  developed.® 

5.9  SUMMARY 

Table  5-3  cites  the  strengths  and  weak¬ 
nesses  of  network  scheduling  techniques. 


Network  scheduling  techniques  such  as 
PERT  and  CPM  are  much  alike  in  provid¬ 
ing  interdependencies,  depth  of  detail,  a 
critical  path  and  slack.  The  SWAN  tech¬ 
nique  provides  simplicity  and  visibility 
through  the  time  scales  that  have  been 
used  for  many  years  in  bar  charts. 

The  choice  between  PERT  and  CPM  de¬ 
pends  primarily  on  the  type  of  program 
and  managerial  objectives.  The  PERT 
method  is  particularly  appropriate  if  there 
is  considerable  uncertainty  in  program  ac¬ 
tivity  times  and  if  it  is  important  to  control 
the  program  schedule  effectively.  On  the 
other  hand,  CPM  is  particularly  appropri¬ 
ate  when  activity  times  can  be  adjusted 
readily  and  when  it  is  important  to  plan  an 
appropriate  trade-off  between  program 
time  and  cost. 

In  reality,  differences  between  current  ver¬ 
sions  of  PERT  and  CPM  are  not  pronounced. 
Most  versions  of  PERT  now  allow  only  a 
single  (most  likely)  estimate  of  each  activ¬ 
ity  time. 

When  several  small  programs  are  to  be 
scheduled,  a  multiprogram  network  might 
be  considered.  In  this  situation,  each  pro¬ 
gram  can  be  treated  as  a  separate  entity  and 
the  entire  set  of  programs  diagrammed 
and  handled  as  one  large  network.  The 
RAMPS  computer  program  is  convenient 
to  apply  in  this  case.  Each  program  in  the 
multiprogram  network  should  be  impor¬ 
tance-weighted  or  priority-constrained; 
this  will  determine  which  programs  to 
schedule  earlier,  which  later. 
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Table  5-3.  Proa  and  Cons  of  Networking 


PROS 

•  Organize  what  would  otherwise  be  confusing,  thereby  allowing  managers  to  make  trade-offs  and 
develop  alternative  plans. 

•  Essential  for  activities  such  as  ship  overhauls,  ship  construction  and  the  manufocturing  of  very 
complex  systems. 

•  Allow  managers  to  predict  shortages  and  act  on  them  early. 

•  Once  prepared,  easy  to  update  and  rework. 

•  Give  managers  more  control  over  events  and  schedules. 

CONS 

•  Only  as  sound  as  the  estimates  they  are  based  on. 

•  Sometimes  very  hard  to  portray  —  too  many  lines  and  intersectiorrs. 

•  Complex  networks,  once  sketched  out  on  a  large  wall  chart,  tend  to  become  the  focus  of  martage- 

ment  attention  when,  in  fact,  there  may  be  factors  not  on  the  chart  that  a  manager  ought  to  be  payktg 
attention  to,  such  as  management/labor  relations. _ 
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LINE-OF-BALANCE-TECHNIQUE 


'To  get  understanding  and  agreement  in 
less  time,  draw  a  diagram." 

— James  T.  McCay* 

6.1  LINE-OF-BALANCE  TECHNIQUE 

Network  scheduling  techniques  are  used 
primarily  in  development  and  other  one¬ 
time  programs.  The  line-of-balance  (LOB) 
technique  is  used  in  repetitive  activities 
such  as  production.  In  production  pro¬ 
grams,  LOB  charts  are  particularly  useful 
to  balance  inventory  acquisition  with  the 
production  process  and  delivery  require¬ 
ments. 

A  LOB  chart  shows  which  control  points 
need  attention  now  to  maintain  future  de¬ 
livery  schedules.  Using  the  LOB  technique, 
reporting  to  customers  or  top  management 
is  quick,  inexpensive  and  graphic.  Charts 
used  for  analysis  and  troubleshooting  are 
suitable  for  at-a-glance  status  reporting. 
Without  a  computer-controlled  production 
process,  the  LOB  technique  doesn't  lend 
itself  readily  to  day-to-day  updating.  How¬ 
ever,  a  monthly  or  weekly  check  usually 
keeps  the  process  on  schedule. 

A  LOB  technique  consists  of  four  elements: 
(1)  objectives  of  the  program,  i.e.,  contract 
schedule  and  actual  deliveries;  (2)  pro¬ 
duction  plan  in  leadtime  format;  (3)  cur¬ 
rent  program  status  or  inventory;  and  (4) 
a  comparison  between  where  the  pro¬ 
gram  is  and  where  it's  supposed  to  be, 
that  is,  program  inventories  versus  the 
LOB.  These  four  elements  are  shown  in 
Figure  6-1  and  described  in  this  chapter. 


6.2  OBJECTIVE  CHART 

The  first  step  in  preparing  the  LOB  is  to 
draw  the  contract  delivery  schedule  on  the 
objective  chart  (Figure  6-1  (A)),  which  shows 
cumulative  units  on  the  vertical  scale  and 
dates  of  delivery  along  the  horizontal  scale. 
The  contract  schedule  line  shows  the  cu¬ 
mulative  units  which  the  contractor  is  com¬ 
mitted  to  deliver  over  the  life  of  the  pro¬ 
gram:^  actual  deliveries  to  date  (cumula¬ 
tive)  are  also  shown. 

6.3  PRODUCTION  PLAN  CHART 

The  second  step  is  to  chart  the  production 
(or  assembly)  plan  (Figure  6-1  (B)).  The 
production  plan  is  a  lead-time  chart:  select 
only  the  most  meaningful  events  as  control 
points  in  developing  this  chart. 

These  meaningful  events  can  be  given  sym¬ 
bols  that  show  whether  they  involve  pur¬ 
chased  items,  subcontracted  parts,  or  parts 
and  assemblies  produced  in-house.  As¬ 
semblies  break  down  into  subassemblies, 
which  break  down  into  parts  or  operations. 
Thus,  one  can  develop  a  production  plan 
for  any  part  or  level  of  assembly. 

The  more  steps  monitored,  the  more  sensi¬ 
tive  and  more  complicated  the  chart  be¬ 
comes.  Generally,  control  points  on  a  single 
chart  should  be  limited  to  50.  If  there  are 
more  than  50,  subsidiary  production  plans 
can  be  used  to  feed  the  top  plan.  Thus,  each 
chart  can  be  kept  simple  and  easy  to  under¬ 
stand.  The  shipping  date  of  subsidiary 
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charts  is  the  point  at  which  a  subprogram 
must  be  ready  to  join  the  overall  schedule. 

On  the  production  plan  chart,  each  moni¬ 
tored  step  is  numbered,  left  to  right.  Step  1 
has  the  longest  lead  time;  the  shipping  date 
is  the  highest-numbered  step.  When  two 
steps  are  done  at  the  same  time,  they  are 
numbered  from  top  to  bottom,  such  as 
steps  8, 9,  and  10. 

The  production  plan  chart  shows  the  inter¬ 
relationships  and  the  sequence  of  major 
steps,  as  well  as  lead  times  required  for 
each  step.  An  understanding  of  the  manu¬ 
facturing  processes  involved  and  sound 
judgment  are  required  to  know  which  step 
and  how  many  steps  must  be  monitored. 
Slack  or  float  times  for  activities  are  not 
considered  when  plotting  the  production/ 
lead-time  chart;  only  the  estimated  time 
(and  latest  finish  point)  for  each  activity  is 
used. 

The  12  control  points  in  the  production 
plan  chart  used  as  an  example  represent 
key  tasks  in  manufacturing  one  lot  of  mis¬ 
siles.  The  plan  indicates  that  control  point 
(1),  fabricate  ballistics  shell,  must  begin  24 
workdays  before  1  January  to  meet  the  first 
scheduled  delivery  of  five  units  by  the  end 
of  December  (see  the  objective  chart).  The 
lead  time  for  other  control  points  can  be 
related  to  the  scheduled  delivery  in  a  simi¬ 
lar  manner. 

In  a  five-day- week  operation,  a  month  gen¬ 
erally  is  recognized  as  having  22  work¬ 
days.  Time  for  in-house  transfer  and  stor¬ 
age  must  be  allowed  in  addition  to  the 
processing  time. 

6.4  PROGRAM  STATUS  CHART 

To  control  production,  the  manager  needs 
monthly  status  information  for  each  con¬ 


trol  point.  The  monthly  status  inventory  is 
a  snapshot  of  the  program  status  —  in 
this  case  on  1  May.  On  the  program  status 
chart  (Figure  6-1(0),  the  bar  for  control 
point  (12)  shows  that  14  units  of  the  prod¬ 
uct  have  been  accepted  by  the  government. 
The  bar  for  control  point  (9)  shows  that  40 
units  of  the  guidance  section  have  been 
assembled.  The  bar  for  control  point  (4) 
shows  that  in-house  fabrication  has  begun 
on  60  fins. 

The  cumulative  numbers  of  units  through 
every  control  point  can  and  should  be 
measured  monthly.  Final  deliveries 
(government  acceptances)  are  shown 
month-by-month  on  the  objective  chart  as 
actual  deliveries. 

6.5  LINE-OF-BALANCE  CHARTING 

To  analyze  how  the  status  of  each  control 
point  on  1  May  will  affect  future  schedules, 
the  LOB  has  been  constructed  to  represent 
the  number  of  units  that  should  have  passed 
through  each  control  point  (cumulatively) 
to  satisfy  the  contract  delivery  schedule. 
This  LOB  is  superimposed  on  the  status 
chart  bars,  which  show  the  status  of  each 
control  point  on  a  particular  w,^te. 

The  difference  between  the  line  and  the  top 
of  the  bar  for  each  control  point  is  the 
number  of  units  behind  or  ahead  of  sched¬ 
ule  as  of  1  May.  Thus,  control  point  (12)  is 
16  units  behind  schedule,  control  point  (9) 
is  5  units  ahead  of  schedule,  and  control 
point  (7)  is  21  units  behind  schedule.  The 
main  impact  of  control  point  (7)  being  be¬ 
hind  schedule  will  be  felt  in  12  workdays, 
which  is  the  lead  time  for  control  point  (7). 
As  of  1  April,  an  insufficient  number  of  air 
vehicle  components  (shell,  fins,  engine)  had 
passed  into  the  assembly  (air  vehicle  body) 
phase.  This  will  adversely  affect  final  de- 
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liveries  12  workdays  hence.  All  other  con¬ 
trol  points  can  be  analyzed  in  the  same 
way. 

To  recap,  the  LOB  is  constructed  in  the 
following  manner; 

•  Select  a  control  point;  for  example, 
(7). 

•  Fromtheproductionplan/lead-time 
chart  (Figure  6-1  (B)),  determine  the  lead 
time  -  the  time  from  the  control  point  to 
shipment  point  (12  workdays). 

•  Using  this  number,  determine  the 
date  that  the  unit  now  at  the  control  point 
should  be  completed.  (May  1  plus  1 2  work¬ 
days  takes  you  just  over  halfway  through  a 
22-workday  month.) 

•  Find  the  point  corresponding  to  this 
date  on  the  contract  schedule  line  and  de¬ 
termine  how  many  units  scheduled  for 
completion  this  represents  by  moving  hori¬ 
zontally  from  the  objective  chart  to  the 
program  status  chart  (they  share  the  same 
vertical  scale). 

•  Draw  a  line  on  the  program  status 
chart  (Figure  6-1(0)  at  the  level  (41  units) 
over  control  point  (7). 

•  Repeat  the  above  for  each  control 
point  and  connect  the  horizontal  lines  over 
the  control  points.  The  resulting  line  is  the 
LOB,  indicating  the  quantities  of  units  that 
should  have  passed  through  each  control 
point  on  the  date  of  the  study  or  inventory 
0  May)  if  the  contract  delivery  schedule 
were  being  met. 

6.6  ANALYSIS 


progress  compares  with  planned  progress. 
Analysis  of  the  charts  can  pinpoint  prob¬ 
lem  areas.  Delays  at  control  point  (7)  in  the 
example  may  have  been  causing  final  de¬ 
livery  problems  throughout  the  contract. 
However,  the  purpose  of  LOB  analysis  is 
not  to  show  what  caused  the  slippage  in  the 
shipping  date,  but  to  detect  potential  fu¬ 
ture  problems. 

In  the  example,  the  government  acceptance 
point  is  control  point  (12).  The  bar  doesn't 
reach  the  LOB;  therefore,  deliveries  are 
behind  schedule.  Control  points  (10)  and 
(11)  are  short.  However,  point  (9)  is  on 
schedule.  Since  point  (10)  depends  on 
points  (8)  and  (9),  we  know  control  point 
(8)  is  the  offender.  Both  points  (7)  and  (8) 
are  short,  but  there  are  more  than  enough 
purchased  items  (engines)  at  control  point 
(6). 

What’s  the  problem  with  control  point  (8)? 
Trace  it  back  to  control  point  (7),  which  is 
seriously  short.  It  is  obvious  that  not  hav¬ 
ing  enough  completed  fins  is  holding  up 
the  whole  process.  Control  points  (2),  (3) 
and  (5)  are  short,  but  are  not  directly  re¬ 
sponsible  for  the  failure  to  meet  the  deliv¬ 
ery  schedule  since  (9)  is  ahead  of  schedule. 
Nevertheless  shortages  at  (2),  (3),  and  (5) 
could  soon  cause  problems  at  (9).  The  prob¬ 
lem  with  the  fins  (7)  should  be  addressed 
before  management  attention  is  devoted  to 
other  short  operations.  The  overages  at 
control  points  (1)  and  (6)  may  be  examined 
from  the  point  of  view  of  inventory  control. 
Updating  the  charts  requires  a  good  status¬ 
reporting  system,  which  can  be  mecha¬ 
nized  if  the  program  is  large  and  complex. 

6.7  SUMMARY 


Using  the  LOB  charts  in  Figure  6-1,  man-  The  LOB  is  a  monitoring  technique  that 
agement  can  tell  at  a  glance  how  actual  gives  prior  warning  of  problems  within  a 
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continuous  production  process.  The  key  is  To  do  LOB,  the  following  is  needed:  (1)  a 
to  catch  problems  in  a  production  process  contract  schedule,  or  objective  chart;  (2)  a 
early;  otherwise,  the  schedule  is  lose.  The  production  plan  or  lead-time  chart  for  the 
LOB  technique  provides  that  warning.  production  process  itself;  (3)  control  points 

cumulative  inventories;  and  (4)  a  program 
Think  of  the  production  process  as  a  natu-  status  chart  on  which  you  will  plot  your 
ral  gas  pipeline.  If  a  bubble  of  air  gets  into  LOB  and  the  cumulative  quantities  of  units 

the  pipeline,  it  will  eventually  be  carried  to  have  passed  through  the  control  points 

the  gas  users,  and  the  users  will  find  their  of  the  assembly/production  process.  Ifthe 

burners  extinguished  as  the  nonflammable  objective  and  program  status  charts  are 

air  reaches  them.  The  manager  of  the  pipe-  given  the  same  vertical  scale,  the  LOB  can 

line  company  or  the  natural  gas  utility,  be  plotted  graphically  from  the  former  to 
doesn't  want  their  clients  to  suffer  blow-  tbe  latter, 
outs  from  air  bubbles  in  their  lines.  The 

same  holds  true  for  the  managers  of  a  con-  Remember  that  the  shape  of  the  LOB  will 

tinuous  production  process.  Waiting  for  change  over  time,  especially  if  the  produc- 

problems  to  show  up  at  the  end  of  the  line  bon  process  has  a  beginning  and  an  end. 

is  a  mistake.  Problems  need  to  be  detected  Remember,  too,  that  LOB  charts  show 

when  they  begin  so  corrections  are  faster,  where  a  problem  is,  but  not  necessarily 

before  too  much  damage  (to  cost,  perfor-  why  the  problem  exists  or  what  the  solu- 

mance  or  schedule)  is  done;  and  produc-  bon  is. 
tion  schedules  fall  too  far  off  contract. 


Table  6-1.  Pros  and  Cons  of  Line  of  Balance 

PROS 

•  Points  out  problems  before  their  impact  on  finished  product  deliveries  show  up,  thereby  allowing 
managers  to  correct  problems  earlier. 

•  Allows  managers  to  see,  in  the  middle  of  a  contract,  whether  they  can  meet  the  contract  schedule 
if  they  continue  working  as  they  have  been. 

•  Focuses  attention  on  those  production  control  points  where  there  are  problems,  which  allows  a 
senior  manager  to  pinpoint  responsibility  for  slippages. 

CONS 

•  People  working  on  a  project  may  not  grasp  what  the  LOB  is  measuring. 

•  Limited  to  production  and/or  assembly-type  processes. 

•  Shows  only  where  the  problem  is,  not  what  it  is. 

•  A  monitoring  device;  not  as  easy  to  use  as  a  planning  device. 


7 

TIME  MANAGEMENT 


It  is  important  that  PMs  manage  time  well. 
PMs  are  busy  people,  particularly  those  in 
the  DoD  and  defense-related  industry. 
Some  managers  could  be  more  productive, 
perhaps  as  much  as  20-40  percent,  by  ap¬ 
plying  ehPective  approaches. 

This  chapter  concerns  three  aspects  of  time 
management  related  to  programs: 

•  PM's  time  reserve; 

•  "Now"  schedule;  and 

•  Value  of  time. 

7.1  PROGRAM  MANAGER'S 
TIME  RESERVE 

In  contractor  performance  measurement, 
much  emphasis  is  placed  on  "management 
reserve,"  the  reserve  budget  controlled  by 
the  industry  PM.  Whatisn'talwaysrecog- 
nized  is  that  a  time  reserve  is  also  needed  in 
order  to  accommodate  unknowns  the  PM 
will  encoimter.  However,  use  of  a  time 
reserve  should  be  approached  with  cau¬ 
tion,  because  members  of  a  program  office 
team  may  be  tempted  to  fall  back  on  it 
prematurely. 

Literature  describing  a  PM's  time  reserve  is 
scarce.  However,  based  on  discussions  with 
a  sampling  of  managers  of  both  large  and 
small  programs,  the  main  aspects  of  a  time 
reserve  are  clear. 

•  Most  PMs  establish  a  time  reserve  of 
about  10  percent.  On  a  40-month  program. 


for  example,  a  4-month  time  reserve  would 
be  established. 

•  The  time  reserve  must  be  held  closely 
by  the  PM.  Otherwise,  every  manager  on 
his/her  program  may  think  "I  know  there's 
a  time  reserve;  therefore,  I  don't  really  have 
to  meet  my  schedule".  The  PM  may  place 
this  reserve  under  "additional  system  tests" 
or  another  downstream  activity.  The  point 
is,  it  shouldn't  be  visible.  (A  built-in  safety 
factor  between  the  manufacturing  sched¬ 
ule  and  the  delivery  schedule  is  often  used.) 

•  A  tough  and  disciplined  approach  to 
meeting  the  published  schedule  is  required 
from  the  start  of  a  program  in  order  to 
maintain  the  reserve  and,  consequently,  to 
meet  the  program  schedule  in  spite  of  slip¬ 
pages  caused  by  the  unknown  unknowns 
(unk  unks)  that  inevitably  arise. 

7.2  "NOW"  SCHEDULE 

There  is  a  direct  relationship  between  time 
and  cost  for  any  activity.  This  relationship 
takes  into  accoimt  the  people,  resources 
and  method  used.  It  also  considers  the 
efficiency  achieved.  Generally,  the  least 
costly  schedule  is  the  current  one.  Speed¬ 
ing  up  the  schedule  costs  more;  stretching 
out  the  schedule  also  costs  more. 

The  sum  of  the  direct  and  indirect  costs 
gives  a  U-shaped  total  program  cost  curve. 
The  optimum  schedule  for  implementing 
the  program  is  the  schedule  corresponding 
to  the  minimum  point  on  this  curve.  The 
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relationship  among  direct,  indirect  and  to¬ 
tal  program  cost  is  shown  graphically  in 
Figure  7-1. 


Ffgura  7*1.  Total  Coat  Analyala  ter  Saloclina 
'OpUimim*  Program  Duration 


Because  schedule  stability  affects  program 
costs,  which  may,  in  turn,  affect  technical 
performance,  it  is  clear  that  schedule  stabil¬ 
ity  has  a  great  deal  to  do  with  whether  the 
program  meets  its  cost  and  technical  objec¬ 
tives.  Unfortunately,  budget  constraints 
and  other  factors,  like  changes  in  quantities 
(items  over  which  the  PM  has  no  control), 
have  often  been  imposed  on  a  program 
with  the  comment,  "Do  the  best  you  can". 

When  a  schedule  must  be  revised,  the  su¬ 
perseded  schedule  is  often  discarded.  If 
the  new  schedule  is  superseded,  the  pro¬ 
cess  is  repeated.  However,  there  is  some 
value  in  retaining  an  obsolete  schedule. 
Often,  the  organization  causing  a  slip  in 
schedule  becomes  a  repeat  offender.  The 
principal  value  of  retaining  a  former  sched¬ 
ule  lies  in  being  able  to  hold  the  offender's 
feet  to  the  fire,  thus  making  schedule  slips 
less  palatable. 

The  significance  of  maintaining  a  stable 
schedule  is  becoming  more  widely  recog¬ 
nized.  Appendix  A  describes  the  develop¬ 
ment  of  a  master  schedule  and  the  impor¬ 
tance  of  maintaining  schedule  discipline. 


73  VALUE  OF  TIME 

According  to  the  late  John  H.  Richardson, 
president  of  Hughes  Aircraft  Company, 
"A  basic  reason  for  adopting  project  (or 
program)  management,  when  tackling  the 
difficult  and  unique  tasks  associated  with 
developing  and  producing  a  system,  is  to 
eliminate  unnecessary  delays  in  accom¬ 
plishing  the  job  at  hand.  Time  is  a  resource 
in  systems  management,  to  be  treated 
with  indifference  or  used  well  like  any 
other  resource.  For  projects  not  yet  in  full 
swing,  it  is  important  to  recognize  that 
time  has  economic  value,  and  that  we  may 
be  taking  time  too  much  for  granted."' 

Richardson  understood  why  managers 
stretched  out  program  schedules. 

•  Funding  could  create  a  problem.  In 
hungry  years,  thescheduleisoftenstretched 
because  of  reduced  funding. 

•  A  better  product  could  be  developed 
if  it  were  more  thoroughly  debugged  and 
tested.  However,  a  system  does  not  really 
get  wrung-out  until  it  is  in  the  user's  hands, 
regardless  of  advance  debugging. 

•  Cost  of  concurrency  (overlap  of  de¬ 
velopment  and  production)  might  lead 
to  a  decision  not  to  overlap  program 
phases.  Such  a  decision  might  be  popular 
in  many  cases,  but  it  could  never  be  toler¬ 
ated  when  the  pendulum  swung  toward 
the  importance  of  time;  that  is,  when  top 
management  said  "Get  the  system  out  the 
door,  never  mind  what  it  costs."^ 

Stretched-out  schedules  incur  cost  penal¬ 
ties  because  of  inflation,  additional  engi¬ 
neering  changes,  and  changes  in  key  pro¬ 
gram  management  office  positions.  An¬ 
other  near-term  cost  is  due  to  the  increased 
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chance  that  a  program  will  be  canceled 
because  of  obsolescence  or  competing 
technology.  Stretch-outs  invite  cancella¬ 
tion.  Also,  long  schedules  with  no  oppor¬ 
tunities  for  incorporation  of  improve¬ 
ments  are  a  negative  factor  when  consider¬ 
ing  a  new  start. 

Delayed  decisions  increase  costs.  Accord¬ 
ing  to  R.  W.  Peterson,  former  DuPont  ex¬ 
ecutive,  "All  businessmen  are  concerned, 
and  proporly  so,  about  the  long  time  it 
takes  to  move  a  new  development  from 
its  inception  to  a  profit  status.  But  fre¬ 
quently  forgotten  is  the  fact  that  a  month's 
delay  in  the  early  stages  of  development 
is  exactly  as  long  as  a  month's  delay  in  the 
later  stages.  While  it  may  seem  innocuous 
to  put  off  a  decision  for  a  month  or  two  in 
the  early  years  of  a  project  (or  program) 
with  an  uncertain  future,  that  delay  may 
turn  out  to  be  just  as  costly  as  is  procrasti¬ 
nation  when  the  final  decisions  are  made. 
In  short,  a  sense  of  urgency  is  essential  to 
decision  making  in  all  stages  of  a  new 
venture,  not  just  the  later  stages."^ 

The  useful  life  of  a  defense  system  must  be 
taken  into  consideration.  Concentration 
on  the  system  or  product  often  overlooks 
a  key  point;  whether  the  buyer  obtains 
value  upon  delivery.  The  most  costly 
product  is  one  that  appTears  when  it  no 
longer  fulfills  a  useful  purpose,  even 
though  it  has  been  produced  at  minimum 
cost.  Each  month  added  to  the  develop¬ 
ment  and  production  of  a  new  high- 
technology  system  or  product  tends  to 
reduce  by  one  month  the  opjerational  life  of 
the  system  or  product. 

In  spite  of  the  10-20  p)ercent  cost  premium 
that  may  be  paid  for  tight  scheduling  (as 


compared  to  orderly  but  stretched-out 
scheduling),  the  resulting  longer  opera¬ 
tional  life  may  provide  greater  economic 
value.  This  is  looking  at  time  only  from  the 
viewpoint  of  economics;  i.e.,  acquisition 
cost  per  year  of  operational  availability. 
Another  way  of  looking  at  time  is  that 
defense  system  availability  is  survival  in¬ 
surance. 

Consideration  of  alternative  plans  and 
schedules  will  also  help;  e.g.,  if  event  so- 
and-so  occurs,  proceed  with  plan  "A";  if 
event  such-and-such  occurs,  proceed  with 
plan  "B"  and  so  on.  Anticipation  and  prepa¬ 
ration  for  most-likely  events,  along  with 
the  tools  described,  and  coupled  with  ef¬ 
fective  communication  of  the  plans,  can 
change  the  management  style  from  crisis 
management  to  skillful  management. 

7.4  SUMMARY 

Planning  and  scheduling  can  do  much  to 
prevent  running  out  of  time  and  having  to 
make  the  least  desirable  decision  because 
of  lack  of  time.  Establishing  a  time  reserve 
and  a  "now"  schedule,  and  recognizing  the 
value  of  time  in  decision  making  all  con¬ 
tribute  to  the  manager's  repertoire  of  good 
tools. 

Sir  Jeffrey  (^uill,  manager  of  the  British 
Spitfire  Development  Program,  com¬ 
mented  during  a  visit  to  DSMC  that;  "After 
1935,  costs  weren't  particularly  important. 
What  mattered  was  time.  We  worked  three 
shifts  a  day.  Everything  was  time.  Quan¬ 
tity  and  time.  It  turned  out  that  we  prob¬ 
ably  produced  at  the  lowest  cost,  too;  but 
the  emphasis  was  on  time." 


a 

AUTOMATED  PLANNING,  SCHEDULING 

AND  CONTROL 


A  PM  must  be  successful  in  managing  all 
aspects  of  the  program.  Projects  must  be 
defined:  human  resources,  materials  and 
budgets  must  be  scheduled  to  complete  the 
projects.  Work  in  progress  must  be  tracked. 
Status  reports  of  progress  and  variances  to 
the  plan  must  be  developed  in  order  to 
revise  schedules,  budgets  and  work  as¬ 
signments.  Today,  there  are  numerous  au¬ 
tomated  applications  available  to  assist  with 
the  chores  of  achieving  system  performance 
in  a  timely  manner  within  budget. 

8.1  BACKGROUND 

Managers  of  the  Navy  Polaris  Submarine 
Program  during  the  1950s,  using  main¬ 
frame  computers,  first  proved  to  the  DoD 
that  automation  would  play  a  major  role  in 
program  management.  These  PMs  recog¬ 
nized  the  benefits  of  automation  when  ap¬ 
plied  to  the  decision-making  process  and 
as  a  planning  and  control  tool.  However,  it 
was  a  very  costly  process,  involving  sig¬ 
nificant  time  for  implementation.  At  that 
time,  automation  was  used  as  a  project 
management  tool  only  on  very  large  pro¬ 
grams. 

Today,  as  predicted  by  the  late  Admiral 
Grace  Hopper  on  her  many  visits  to  DSMC, 
automation  has  made  a  profound  impact 
on  the  processes  of  program  manage¬ 
ment.  The  microcomputer  has  multiplied 
the  capabilities  and  productivity  of  each 
member  of  the  program  management 
team.  Hundreds  of  software  applications 


are  able  to  provide  PMs  with  automated 
scheduling  tools  and  project  management 
capabilities.  Most  of  these  applications  are 
commercial  packages  that  can  be  purchased 
off-the-shelf  at  most  computer  stores  or 
from  the  General  Services  Administration 
(GSA)  approved  contract  schedules.  The 
services  have  also  developed,  in-house  or 
through  support  contractors,  numerous 
applications  tailored  to  acquisition 
management.  Some  have  shells  or  tem¬ 
plates  to  organize  projects,  while  others 
may  serve  as  automated  listings  of  perti¬ 
nent  tasks  to  be  completed  over  the  life 
cycle  of  the  program  or  project. 

8.2  REQUIREMENTS  DEFINITION 

The  decision  about  which  project  man¬ 
agement  software  applications(s)  to  buy 
should  only  be  made  following  a  careful 
understanding  of  the  need  for  such  a  dy¬ 
namic  product.  The  PM  must  review  the 
types  of  projects  to  be  managed  and  the 
functional  people  who  will  interface  with 
the  acquisition  environment  and  use  the 
software.  An  accurate  analysis  of  the  need 
will  provide  a  stronger  foundation  for  suc- 
cess^l  selection  of  the  "right"  program  to 
meet  that  need.  A  clear  definition  of  the 
requirement  will  assist  in  narrowing  down 
the  software  alternatives,  which  vary  sig¬ 
nificantly  in  price  and  capability.  Various 
criteria  must  be  established  to  measure  the 
impact  upon  cost,  schedule,  performance 
and  suitability  when  deciding  which  soft¬ 
ware  to  buy. 
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83  NATURE  OF  PROGRAMS/ 
PROJECTS 

The  fundamental  goal  of  program  man¬ 
agement  is  to  achieve  success  in  develop¬ 
ing  and  fielding  a  system  that  meets  the 
performance  requirements  of  the  user, 
when  needed  and  within  affordable  cost 
limits.  This  is  accomplished  through  the 
optimization  of  resource  constraints,  time 
and  relationships  among  tasks.  Some  pro¬ 
grams  or  projects  may  be  categorized  as 
resource-constrained,  where  the  schedule 
depends  more  on  the  availability  of  re¬ 
sources,  while  others  may  be  event-driven, 
where  the  schedule  depends  more  on  the 
tasks  and  their  interdependencies.  Sched¬ 
ule  risk  can  be  optimized  through  the  con- 
ciurent  scheduling  of  activities  that  have 
less  dependency  upon  sequenced  comple¬ 
tion.  Schedule  risk  can  also  be  traded  off 
with  cost  by  reducing  the  time  required 
to  complete  those  activities  on  the  critical 
path,  thus  accelerating  completion  of  the 
entire  project. 

According  to  Danek  Bienkowski,'  author 
of  "Selecting  and  Implementing  Project 
Management  Software",  Journal  of  Informa¬ 
tion  Systems  Management,  Fall  1988,  re¬ 
source-constrained  and  time-constrained 
projects  should  be  managed  differently, 
since  each  requires  different  tools. 
Bienkowski  said  that  resource-con- 
strained  projects  require  the  Gantt  chart 
for  primary  emphasis,  with  the  PERT  net¬ 
work  used  as  support,  whereas  time-con¬ 
strained  projects  are  effectively  managed 
using  PERT  networks  primarily,  with 
Gantt  charts  in  the  support  role.  He  also 
pointed  out  that  it  is  important  to  remem¬ 
ber  this  distinction  when  selecting  project 
management  software,  because  some 
packages  are  Gantt-oriented  while  others 
are  PERT-oriented.  Some  commercial  soft¬ 


ware  packages  have  strong  resource  fea¬ 
tures  while  others  lack  this  advantage. 

When  choosing  a  software  package,  atten¬ 
tion  should  also  be  given  to  whether  or  not 
the  agencies  or  organization  associated  with 
the  project  are  already  using  a  project  man¬ 
agement  package  and  if  compatibility  with 
that  software  would  be  necessary.  A  cost- 
benefit  analysis  of  compatibility  is  a  useful 
approach  to  addressing  this  issue. 

8.4  SIZE  OF  THE  PROGRAM/ 
PROJECT 

The  size  and  complexity  of  the  program/ 
project  is  another  major  criterion  that 
should  be  used  in  selecting  a  software  pack¬ 
age.  How  many  tasks  are  required  to  com¬ 
plete  the  project?  There  may  be  fewer  than 
a  hundred,  or  perhaps  thousands  must  be 
tracked.  Some  commercial  packages  can 
track  only  several  hundred  activities,  while 
others  may  be  unlimited  except  for  your 
disk  memory.  Some  packages  will  allow 
assignment  of  many  resources  to  a  project 
or  task  while  others  may  not. 

Similar  importance  should  be  placed  upon 
consideration  of  time  scales.  Many  pack¬ 
ages  will  not  allow  you  to  schedule  less 
than  a  day  while  others  will  let  you  break 
down  the  program  structure  to  the  hour 
level.  Other  time  concerns  may  be  consid¬ 
ered,  such  as  the  maximum  duration  al¬ 
lowed  for  a  task  and  the  maximum  project 
length  in  time;  e.g.,  100  years. 

8.5  ADVANCED  FEATURES 

Today,  project  management  software  pro¬ 
grams  are  able  to  offer  open  database  con¬ 
nectivity,  which  allows  users  to  link  their 
projects  with  other  databases.  This  per¬ 
mits  rapid  updates  of  project  data,  such  as 
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activity  identification  and  durations, 
availability  of  personnel  and  their  wages, 
and  other  costs  associated  with  each  work 
package.  Larger  packages  enable  the  user 
to  load  and  access  multiple  projects  in  or¬ 
der  to  share  common  resource  pools  and 
automatically  level  resource  assignments 
across  all  projects. 

8.6  COST 

Generally,  software  decision  criteria  will 
not  be  complete  without  consideration  of 
cost.  The  commercial  packages  vary  in 
price  from  less  than  a  hundred  dollars  to 
thousands  of  dollars.  The  cost  of  acquisi¬ 
tion  is  a  particularly  important  consider¬ 
ation  when  a  large  number  of  the  software 
packages  is  required  to  support  many  pro¬ 
gram  management  team  members. 

The  capability  of  the  package  to  handle 
cost  within  the  project  is  also  an  essential 
performance  consideration.  Some  pro¬ 
grams  do  an  eamed-value  calculation  and 
complete  a  cost  distribution  or  cash  flow 
analysis.  Less  complex  programs  provide 
for  the  accounting  of  costs  as  a  fixed 
amount  charged  to  a  task  or  activity.  More 
capable  programs  allow  the  cost  to  be  ac¬ 
crued  from  the  scheduled  use  of  resources 
as  actuals  are  entered  into  the  program. 


8.7  REPORTS  AND  DISPLAYS 

The  reports  generated  within  the  software 
may  be  one  of  the  most  essential  consider¬ 
ations  in  selecting  a  commercial  package. 
Displays  of  charts,  networks  and  other  pre¬ 
sentations  should  be  considered  among 
the  primary  criteria  since  they  readily  de¬ 
termine  whether  or  not  a  package  meets 
nunimiun  requirements  to  assist  the  PM  in 
managing  a  project  successfully.  Figure  8- 
1  shows  an  example  of  a  Gantt  chart  pro¬ 
duced  as  a  standard  display  from  a  com¬ 
mercial  package.  It  provides  a  summary 
of  the  activities,  the  total  daily  resource 
allocation  for  identified  resources,  and  the 
t5rpical  horizontal  lines  in  proportion  to 
time. 

Today,  many  of  the  software  packages  pro¬ 
vide  multiple  views  of  the  project.  While 
many  have  separate  displays,  n\any  more 
provide  for  combined  displays,  such  as  the 
ability  to  view  simultaneously  the  task  list, 
planned  and  actual  activities  in  a  Gantt 
time-scaled  horizontal  bar  chart,  and  a  his¬ 
togram  reflecting  cumulative  usage  of  work 
hours  expended.  Some  packages  provide 
a  spreadsheet  option  associated  with  each 
task  or  activity;  thus,  program  financial 
sheets  can  be  generated,  as  well  as  chart- 
type  reports.  Another  strong  feature  pro- 


Figure  8-1.  Gantt  Chart 


vided  by  modern  packages  is  the  ability  to 
resource  breakdown  structure.  A  com¬ 
bined  V  ■  w  of  these  capabilities  generates  a 
responsibility  matrix  that  can  be  very  use¬ 
ful  in  converting  work  packages  into  ex¬ 
ecutable  schedules  which  the  PM  may  rely 
upon  for  success. 

Figure  8-2  represents  a  condensed  over¬ 
view  of  a  PERT/CPM  network  that  is  a 
standard  display  from  a  commercial  pack¬ 
age.  It  provides  a  symbolic  level  of  detail 
which  is  simplified  by  the  legend.  The 
same  package  also  provides  expanded  pre¬ 
sentations;  which,  include  more  detailed 
information  such  as  early  start  times,  lat¬ 
est  start  times  and  task  duration.  An¬ 
other  Network/Gantt  commercial  pack¬ 
age  display,  used  during  the  planning  and 
execution  of  DSMC  95  (a  curriculum  rede¬ 
sign  and  reorganization  project),  is  shown 
in  Appendix  D. 


Figuiv  8-2.  standard  Display,  PERT/CPM  Network 


The  standard  display  formats  of  alterna¬ 
tive  packages  should  be  reviewed  for  suit¬ 
ability.  The  extent  to  which  they  can  be 


customized  should  also  be  considered.  The 
more  powerful  programs  provide  greater 
flexibility,  but  are  more  compUcated  to  use. 

8.8  OTHER  CONSIDERATIONS 

Other  considerations  may  be  given  a  higher 
priority  when  selecting  program  manage¬ 
ment  software  packages.  Among  them  are 
compatibility  and  support.  Commercial 
packages  contain  a  wide  variety  of  import 
and  export  capabilities  that  enable  the  man¬ 
ager  to  interface  with  other  software  appli¬ 
cations  that  may  already  be  m  use.  This 
interoperability  or  integration  capability 
may  save  many  dollars  through  reduced 
data  entry  and  processing  time.  There  may 
also  be  opportunities  for  savings  on  sup¬ 
port  for  the  package.  Producers  of  these 
commercial  packages  offer  various  levels 
of  support  such  as  training,  consulting  on¬ 
site  and  by  professionally  staffed  hotlines, 
newsletters,  warranties  and  promotion  of 
user  groups. 

8.9  SUMMARY 

The  selection  of  appropriate  project  man¬ 
agement  software  may  be  a  complex  pro¬ 
cess  due  to  the  range  of  capabilities,  their 
mix,  and  the  cost  of  associated  packages. 
However,  if  sufficient  effort  is  made  up¬ 
front  to  identify  the  requirements  clearly 
and  to  examine  the  alternatives  thoroughly, 
the  PM  will  make  a  much  better  decision  in 
ensuring  the  successful  satisfaction  of  his/ 
her  need. 
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9 

RECAPITULATION 


The  PM  is  responsible  to  top  management 
for  getting  the  job  done  on  schedule  and 
within  the  allowable  cost.  Today,  network- 
based  systems  assist  the  PM  in  planning, 
scheduling  and  controlling  the  work  to  be 
accomplished  —  often  by  people  in  sepa¬ 
rate  organizations  not  under  the  manager's 
direct  control.  The  PM  needs  a  plan  that 
will  provide  a  constant  and  up-to-date  pic¬ 
ture  that  is  understood  by  all. 

Scheduling,  cost  and  performance  are  ma¬ 
jor  elements  of  concern  to  the  PM,  who 
should  be  able  to  blend  them  to  meet  pro¬ 
gram  objectives.  When  selecting  a  sched¬ 
uling  method,  the  PM  can  make  a  con¬ 
scious  trade-off  between  the  sophisticated 
methods  available  and  cost. 

9.1  PRINCIPAL  POINTS 

The  principal  points  to  be  derived  from  this 
guide  are  the  following: 

•  Schedule,  time  and  cost  are  the  three 
major  elements  to  control  in  any  program. 
These  can  be  in  conflict;  therefore,  trade¬ 
offs  may  have  to  be  made. 

•  All  programs  involve  planning, 
scheduling  and  controlling.  E>uring  the 
planning  phase,  objectives,  organization 
and  resources  are  determined.  During  the 
scheduling  phase  —  the  phase  with  which 
this  guide  is  concerned  —  personnel  re¬ 
quirements  have  to  be  determined,  and 
time  to  complete  the  work  and  the  cost 
have  to  be  estimated.  During  the  control 
phase,  the  program's  progress  in  terms  of 


time,  cost  and  performance  have  to  be  mea¬ 
sured.  Necessary  corrections  have  to  be 
made  to  ensure  achievement  of  the  pro¬ 
gram  objectives. 

•  The  activity-oriented  Gantt  charts  are 
useful  when  activities  are  not  closely  re¬ 
lated  and  the  program  is  relatively  small. 
The  chart's  value  is  its  ease  of  preparation 
and  use,  along  with  its  ability  to  show  key 
activities  with  specific  start  and  comple¬ 
tion  times. 

•  The  milestone  charts,  which  are 
event-oriented,  will  indicate  progress  by 
displaying  start  and  completion  dates,  but 
may  invite  surprises  because  the  PM  may 
not  know  the  program  status  until  an  event 
occurs,  or  fails  to  occur. 

•  The  network  displays  how  a  pro¬ 
gram  can  be  done  by  depicting  activities 
and  their  relationships.  The  schedule  es¬ 
tablishes  how  it  is  planned  by  showing  the 
time  it  takes  to  get  done. 

•  A  network  identifies  the  critical  path, 
slack  (time  an  activity  or  event  can  be  ex¬ 
tended  and  still  be  completed  on  time)  and 
activities  needing  rescheduling.  Activities 
on  the  critical  path  have  zero  slack  and 
must  be  completed  on  time  to  prevent  slip¬ 
page  of  the  overall  program  completion 
date. 

•  The  CPM,  a  network-based  schedul¬ 
ing  method,  uses  a  linear  time-cost  trade¬ 
off;  i.e.,  it  adds  the  concept  of  cost  to  the 
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PERT  format.  If  necessary,  each  activity 
can  be  completed  in  less  than  normal  time 
by  crashing  the  activity  for  a  given  cost. 

•  The  LOB  technique  of  scheduling  is 
effective  in  manufacturing  where  a  final 
assembly  line  is  fed  by  many  component 
lines  and  delivery  of  end-units  is  required 
at  predetermined  specified  intervals.  Ef¬ 
fectiveness  of  LOB  is  based  on  the  design  of 
the  assembly  plan. 

•  Computer  programs  are  available 
for  network-based  scheduling.  Manual 
calculations  are  feasible  for  small  prob¬ 
lems  like  those  set  forth  in  this  guide; 


however,  computer  assistance  is  almost  a 
necessity  for  large  and  complex  networks. 

•  Network-theory  assumptions  that 
activities  are  independent,  discrete  and 
predictable  are  not  always  appropriate  in 
actual  applications.  The  departure  from 
reality;  however,  does  not  normally  affect 
planning  and  coordinating  efforts  in  criti¬ 
cal-path  scheduling. 

This  guide  has  presented  a  brief  descrip¬ 
tion  of  the  basic  elements  of  program  sched¬ 
uling.  These  elements  constitute  one  com¬ 
ponent  of  the  overall  management  systems 
in  use  today. 
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APPENDIX  A 

INTEGRATED  MASTER  SCHEDULE 


The  master  schedule  for  a  program  should 
be  a  time  reference  baseline  for  the  pro¬ 
gram.’  To  do  this,  it  must  be  kept  up-to- 
date  with  an  approved  program  for  cost, 
schedule  and  performance.  An  approved 
program  is  one  incorporating  an  officially 
approved  schedule  to  achieve  approved 
performance  levels  within  approved  cost 
allocations.  Maintenance  of  the  master 
baseline  is  a  task  akin  to  that  inherent  in 
configuration  control. 

Program  changes,  whatever  the  source, 
start  as  proposals  and,  if  approved,  grow 
into  a  firm  plan.  Eventually,  they  are  incor¬ 
porated  into  the  program  as  changes.  The 
question  of  when  to  plot  these  changes  is  a 
matter  of  judgement  and  should  reflect  the 
PM's  policy.  Each  change  should  be  plot¬ 
ted  as  a  proposed  or  tentative  change  until 
approv^. 

A  permanent  record  of  each  change 
should  be  maintained.  If  the  program 
schedule  slips,  it  should  be  documented 
until  documentation  no  longer  serves  a 
useful  purpose. 

Schedule  Discipline 

The  degree  of  schedule  discipline  imposed 
within  the  program  management  office 
(PMO)  can  be  a  major  factor  in  the  use  of 
the  master  schedule.  Whenever  copies  of 
the  master  schedule  are  made,  they  should 
be  dated  and  authenticated  by  the  signa¬ 
ture  of  the  PM  or  the  appointed  schedule 
manager.  Undated  and  unauthenticated 


schedules  should  not  be  released  outside 
the  PMO. 

These  are  simple  rules,  but  they  are  not 
practiced  by  many  PMs.  Consequently, 
programs  suffer  from  unauthorized  re¬ 
lease  of  schedule  information  that  has  not 
been  integrated  into  the  master  schedule 
and  has  not  been  approved  by  the  PM. 

Program  Reviews 

The  master  schedule  can  be  a  framework 
for  periodic  program  reviews  within  the 
PMO.  Ifconstructed  properly,  the  schedule 
will  illustrate  the  top-most  levels  of  the 
program  and  will  be  compatible  with  the 
program  cost/schedule  control  system 
reports. 

Program  reviews  can  be  an  excellent  forum 
for  resolution  of  schedule  conflicts  and  the 
genesis  for  controlled  changes  to  the  sched¬ 
ule  from  within  the  PMO.  Most  key  mem¬ 
bers  of  the  PMO  team  are  present  at  these 
reviews;  therefore,  proposed  schedule 
changes  or  slips  can  receive  wide  dissemi¬ 
nation  within  the  organization. 

"What  If  Exercises 

The  master  schedule  can  serve  as  the  frame¬ 
work  for  "what  if  exercises  imposed  on 
programs  from  outside  the  PMO.  Sched¬ 
ule  changes  can  be  plotted  manually  by 
using  overlays.  Using  the  same  grid  coor¬ 
dinates  on  an  overlay  allows  the  PMO 
team  to  see,  clearly  and  graphically,  the 
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effect  of  the  compressions  or  extensions  of 
sub-milestones  on  the  program.  It  may  be 
even  easier  (and  more  productive)  for  the 
PMO  team  to  run  "what  if  exercises  on  a 
computerized  schedule. 

Without  a  master  schedule  as  a  baseline, 
these  exercises  can  take  longer  to  accom¬ 
plish  and  they  may  overlook  important 
variances  from  the  program's  established 
baseline  schedule  or  plan. 

Program  Briefings 

The  master  schedule  can  serve  as  a  baseline 
for  program  reviews  at  higher  headquar¬ 
ters  and  other  reviews  or  briefings  outside 
the  PMO.  Most  programs  have  key  mile¬ 
stones  taken  from  the  master  schedule  and 
presented  in  summary  form  on  viewgraphs 
or  slides.  If  these  do  not  show  the  detail 
required  to  make  a  point,  the  time  span 
shown  can  be  reduced  to  the  point  where 
the  details  become  visible. 

The  master  schedule  can  be  transported 
with  the  team  accomplishing  the  briefing, 
but  this  is  not  recommended.  Extensive 
handling  of  the  schedule  chart  can  cause 
unnecessary  wear  and  may  result  in  a  need 
to  redraw  it.  This  can  be  a  significant  task 
because  the  master  schedule  may  be  7'  x  10' 
or  as  large  as  10'  x  15'. 

Conclusion 

The  PM  should  remember  the  following 
guidelines: 


•  Have  an  integrated  schedule  pre¬ 
pared  in  the  PMO  and  maintain  control. 

•  Not  overestimate  the  job.  A  few 
smart  people  on  the  program  team  can  do 
amazing  things  in  7-10  days. 

•  Not  try  to  get  too  fancy  too  fast. 
Keep  the  schedule  simple  until  the  PMO 
team  has  mastered  the  program  and  the 
basics  of  the  process. 

•  Use  the  schedule  as  a  basic  manage¬ 
ment  tool  and  make  it  compatible  with  the 
WBS  and  contract  structure. 

•  Instill  discipline  in  the  team.  The 
PM  should  not  allow  program  schedule 
changes  to  leave  the  PMO  until  he /she  has 
reviewed  and  approved  them.  He/she 
should  be  sure  every  team  member  works 
to  the  same  schedule. 

•  Plan  for  the  unknown.  The  PM 
should  not  approach  complex  events, 
like  source  selection  or  DAB  reviews,  with 
only  a  viewgraph-level  plan. 

•  Not  accept  an  incomplete  sched¬ 
ule  when  assigning  the  effort  to  a  member 
of  the  PMO  team.  An  incomplete  schedule 
could  lead  to  program  problems  or  a  can¬ 
celled  program. 
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APPENDIX  B 

NETWORK  SCHEDULING  PROBLEM 


In  paragraph  5.6,  you  were  asked  to  solve  a 
network  scheduling  problem.  Here  are  two 
solutions.  The  first,  submitted  by  CDR 
Eric  Gregory,  USN,  was  computed  manu¬ 
al  "^he  second,  prepared  by  LTC  Robert 


Shively,  USA,  was  computer-generated, 
illustrating  what  commercially  available 
software  can  do  for  the  planner  and  man¬ 
ager.  They  are  referred  to  as  "School"  Solu¬ 
tion  #1  and  "School"  Solution  #2. 
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Missile  Mlvwy 
Scheduling  Problem 
(Initial  Coition) 
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NETWORK  DIAGRAM  -  STARTING 


SMC  84)  Oiy« 


ProjMt:  EX8TART 


#  Resource  Capacity 


1  1-2 

2  1-3 

3  1-4 

4  1-5 

5  2-6 

6  2-3 

7  3-5 

8  4-5 

9  5-6 

10  6-7 

11  7-8 


Cost  to  complete: 


Mlaalle  Delivery 
Scheduling  Problem 
(Initial  Condition) 


Unit  Coat 


Date:  Feb  3. 1994  2:46  PM 


Days  to 
Complete 


Cost  to 
Complete 


Cost  of  Projsct  $736,500. 


Project:  EXFINAL 


#  Resource  Capacity 


1  1-2 

2  1-3 

3  1-4 

4  1-5 

5  2-6 

6  2-3 

7  3-5 

8  4-5 

9  5-6 

10  6-7 

11  7-8 


Cost  to  complete: 


Missile  Deiivsry 
Scheduling  Problem 
(Revised  to  56  days) 
(After  crashing) 


Unit  Cost 


Date:  Feb  3, 1994  3:07  PM 


Days  to 
Complete 


Cost  to 
Complete 


Cost  of  Project  $778 


APPENDIX  C 
GLOSSARY 


The  following  is  a  glossary  of  basic  project  managen\ent  terms. 

ACTIVITY  —  A  task  or  measurable  amoimt  of  work  to  complete  a  job  or  part  of  a  project. 

BASELINE  —  A  defined  quantity  or  quality  of  performance  used  as  a  starting  point  for 
subsequent  progress  measurement.  The  most  common  baseline  is  cost,  schedule  and 
performance.  Control  of  cost  and  schedule  would  be  assisted  by  project  management 
packages,  while  each  is  traded  off  with  performance. 

CRITICAL  PATH  METHOD  (CPM)  —  A  technique  that  assists  with  determination  of 
early  and  late  start  times  for  activities  based  upon  dependency  of  other  activities  and  the 
time  required  to  complete  them.  Activities  which,  when  delayed,  have  an  impact  on  the 
total  project  schedule,  are  critical  and  are  said  to  be  on  the  critical  path. 

FLOAT/SLACK  —  The  period  of  time  that  an  activity  may  be  delayed  without  becoming 
a  critical  activity. 

GANTT  CHART  —  A  graphic  portrayal  of  a  project  which  shows  the  activities  to  be 
completed  and  the  time  to  complete  them  as  represented  by  horizontal  lines  drawn  in 
proportion  to  the  duration  of  the  activity.  Some  Gantt  charts  will  be  able  to  show  the  float 
for  the  activity. 

MILESTONE  —  An  event  in  the  project  which  marks  a  control  point,  major  accomplish¬ 
ment  or  significant  decision  point. 

PERT  CHART  —  A  graphic  portrayal  of  milestones,  activities  and  their  dependency 
u|X)n  other  activities  for  completion  of  a  project;  also  depicts  the  project's  critical  path, 
which  is  the  longest  path  of  activities  for  a  project. 

RESOURCE  —  Any  person,  tool,  equipment  or  material  used  to  complete  an  activity  or 
task. 

RESOURCE  LEVELING  —  A  process  whereby  resources  are  sorted  out  among  tasks  and 
activities  to  identify  and  avoid  conflicts  between  scheduling  and  availability. 

WORK  BREAKDOWN  STRUCTURE  (WBS)  —  An  organized  method  used  to  break 
down  a  project  into  logical  subdivisions  or  subprojects  at  lower  and  lower  levels  of  detail. 
It  is  very  useful  in  organizing  a  project. 
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DSMC  95  NETWORK  &  GANTT  CHART 


MMMNod* 


GANTT  CHART  REPORT 
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